xiaohe wrote:

默认是在用户目录下启动，自然是存到后面那个路径里。如果想存到前面那个路径，需要在C:/veighna_studio/启动
老师您好，抱歉又来打扰了。今天开盘出现了之前说的存不了数据的问题，我在每个关键节点都打印信息排查了一下，发现程序卡在sqlite_database.save_tick_data的upsert环节（一直卡住，重启后才正常），因此才会出现on_tick有数据但数据库里没有数据的情况。
我觉得可能的原因有两个：1、有别的程序占用了CPU资源导致写入数据这一步无法执行；2、有别的线程在读取sqlite(我确定没有别的写入线程，但有读取的线程)，导致sqlite出错。
我IT基础比较弱，可能没有切中要害。请问您判断这个bug出现的原因可能是什么呢？谢谢！

你确定是没有写入吗？先启动一下图形窗口，加载datamanager模块刷新一下，看看里面有没有数据

七月雪 wrote:

你确定是没有写入吗？先启动一下图形窗口，加载datamanager模块刷新一下，看看里面有没有数据
确定的，从一开始这个问题的表现就是ui界面行情数据能跳动，但database里没有数据，而且这个bug是偶发的，平均10天才发生一次
今天我打印了行情，发现刚开盘的10秒收到的tick数量是之前的4倍多，这也是触发bug的表面上的条件。

我大概找到原因了，但不知道对不对，请大佬们指教：
我观察了下今天收到的数据，前10秒每个品种在每个时间戳都收到了4条重复的tick data，那么在入库的时候，用DbTickData.insert_many(c).on_conflict_replace().execute()批量存储的时候，如果c中有完全重复的数据，就会导致异常，无法执行操作。

bill-wong wrote:

我大概找到原因了，但不知道对不对，请大佬们指教：
我观察了下今天收到的数据，前10秒每个品种在每个时间戳都收到了4条重复的tick data，那么在入库的时候，用DbTickData.insert_many(c).on_conflict_replace().execute()批量存储的时候，如果c中有完全重复的数据，就会导致异常，无法执行操作。

1. 数据库的去重主键，基于symbol、exchange、interval、datetime四个字段，如果完全重复就会去重覆盖
2. 如果插入失败，正常也会抛出异常信息，而不会直接卡住了

目前用的就是默认SQLite吗？

MTF wrote:

bill-wong wrote:

我大概找到原因了，但不知道对不对，请大佬们指教：
我观察了下今天收到的数据，前10秒每个品种在每个时间戳都收到了4条重复的tick data，那么在入库的时候，用DbTickData.insert_many(c).on_conflict_replace().execute()批量存储的时候，如果c中有完全重复的数据，就会导致异常，无法执行操作。

1. 数据库的去重主键，基于symbol、exchange、interval、datetime四个字段，如果完全重复就会去重覆盖
2. 如果插入失败，正常也会抛出异常信息，而不会直接卡住了

目前用的就是默认SQLite吗？
是的，您说得对，今天又卡住了，不是重复数据问题。我用的是sqlite。目前不知道是什么原因了。

bill-wong wrote:

xiaohe wrote:

默认是在用户目录下启动，自然是存到后面那个路径里。如果想存到前面那个路径，需要在C:/veighna_studio/启动
老师您好，抱歉又来打扰了。今天开盘出现了之前说的存不了数据的问题，我在每个关键节点都打印信息排查了一下，发现程序卡在sqlite_database.save_tick_data的upsert环节（一直卡住，重启后才正常），因此才会出现on_tick有数据但数据库里没有数据的情况。
我觉得可能的原因有两个：1、有别的程序占用了CPU资源导致写入数据这一步无法执行；2、有别的线程在读取sqlite(我确定没有别的写入线程，但有读取的线程)，导致sqlite出错。
我IT基础比较弱，可能没有切中要害。请问您判断这个bug出现的原因可能是什么呢？谢谢！
程序一直卡在那个环节，指的是程序一直在运行吗，还是指整个电脑屏幕卡住了？其他电脑程序有没有受到影响？

七月雪 wrote:

bill-wong wrote:

xiaohe wrote:

默认是在用户目录下启动，自然是存到后面那个路径里。如果想存到前面那个路径，需要在C:/veighna_studio/启动
老师您好，抱歉又来打扰了。今天开盘出现了之前说的存不了数据的问题，我在每个关键节点都打印信息排查了一下，发现程序卡在sqlite_database.save_tick_data的upsert环节（一直卡住，重启后才正常），因此才会出现on_tick有数据但数据库里没有数据的情况。
我觉得可能的原因有两个：1、有别的程序占用了CPU资源导致写入数据这一步无法执行；2、有别的线程在读取sqlite(我确定没有别的写入线程，但有读取的线程)，导致sqlite出错。
我IT基础比较弱，可能没有切中要害。请问您判断这个bug出现的原因可能是什么呢？谢谢！
程序一直卡在那个环节，指的是程序一直在运行吗，还是指整个电脑屏幕卡住了？其他电脑程序有没有受到影响？

一直在运行，只是写数据库的进程卡住了，行情接收之类的没收到影响。其他程序也没有受到影响。

bill-wong wrote:

MTF wrote:

bill-wong wrote:

我大概找到原因了，但不知道对不对，请大佬们指教：
我观察了下今天收到的数据，前10秒每个品种在每个时间戳都收到了4条重复的tick data，那么在入库的时候，用DbTickData.insert_many(c).on_conflict_replace().execute()批量存储的时候，如果c中有完全重复的数据，就会导致异常，无法执行操作。

1. 数据库的去重主键，基于symbol、exchange、interval、datetime四个字段，如果完全重复就会去重覆盖
2. 如果插入失败，正常也会抛出异常信息，而不会直接卡住了

目前用的就是默认SQLite吗？
是的，您说得对，今天又卡住了，不是重复数据问题。我用的是sqlite。目前不知道是什么原因了。

尝试换个高性能数据库试试，例如：dolphinDB,MongoDB。