Есть проблема, с которой борюсь довольно давно, но к сожалению, так ее и не удалось решить, и похоже все дело именно в связке QUIK-QLua-Lua. Я написал скрипт на Lua, который периодически записывает данные о параметрах опционов (волатильность и т.д.) в БД, чтобы в дальнейшем использовать данную информацию для сложных запросов. Для записи в БД пробовал пользоваться несколькими сторонними библиотеками: LuaSQL () и LuaSQLite3 (). При этом в случае LuaSQL пробовал реализацию для sqlite и mysql. Сами библиотеки прикрутить к QUIK'у удалось, хотя это непросто. Но итоговый результат к сожалению печальный: скрипт работает определенное время, делает записи в БД, как надо, но потом QUIK просто падает (без дампа, без всего). Если записи в БД делать два раза в секунду, то падает через несколько минут. Если писать раз в минуту (как изначально мной предполагалось), то падает через полчаса, а может через пару часов. Мне нужна стабильная работа в течение всего дня. За одну итерацию пишу около сотен строк в БД, что полная ерунда для современных мощностей. Смотрел на использование ЦП QUIK'ом во время работы скрипта - все нормально. Пробовал запись как из потока main, так и из функций обратного вызова - результат один и тот же. То, что один и тот же результат воспроизводится для различных библиотек и различных СУБД, говорит о том, что дело не в них, а в QUIK'е или QLua. Если записывать все нужные данные просто в файл csv, а не в БД, то все стабильно работает. По опыту могу сказать, что падение может быть вызвано ошибкой при одновременном доступе к одному участку памяти в QUIK'е или запил памяти, но так как у меня нет исходного кода ни qlua.dll, ни quik.exe, то я не могу ничего сказать и сделать. Неужели моя задача никак не решается с использованием QUIK? Хотелось бы получить ответ от разработчиков. Я могу дать код скрипта, если нужно. Пробовал на версиях QUIK 7.14 и 7.16.
Пользователь
Сообщений: Регистрация: 10.04.2015
24.05.2018 03:00:07
Цитата
Сергей написал: То, что один и тот же результат воспроизводится для различных библиотек и различных СУБД, говорит о том, что дело не в них, а в QUIK'е или QLua.
Цитата
Сергей написал: Если записывать все нужные данные просто в файл csv, а не в БД, то все стабильно работает.
Первое утверждение противоречит второму. Косяк явно в коде работы с БД.
Попробуйте вынести весь свой скрипт в отдельный процесс через LuaRPC (найдите любую реализацию в сети, к примеру, есть готовая под QLua: ), и посмотрите, какой процесс у вас будет падать в итоге...
Пользователь
Сообщений: Регистрация: 06.04.2017
24.05.2018 09:13:08
Цитата
Suntor написал: Первое утверждение противоречит второму. Косяк явно в коде работы с БД.
Не вполне пойму, в чем противоречие. У меня в скрипте довольно тонкая прослойка к упомянутым третьесторонним библиотекам - открываю соединение, получаю данные из QUIK'а о нужных инструментах, делаю вызов INSERT, как в примере . У LuaSQLite3 другой API и обращение к другой dll - и падение то же самое повторяется. Если бы в моем скрипте была бы ошибка, то не работало бы вообще.
Цитата
Suntor написал: Попробуйте вынести весь свой скрипт в отдельный процесс через LuaRPC (найдите любую реализацию в сети, к примеру, есть готовая под QLua: quik-lua-rpc), и посмотрите, какой процесс у вас будет падать в итоге...
Не очень знаком с технологиями "Protocol Buffers", "ZeroMQ", которые тут указаны. Я так понял смысл в том, что мой скрипт будет запущен обычным интерпретатором Lua и будет RPC-клиентом. Для получения данных из QUIK он будет делать RPC вызовы на скрипт (RPC-сервер) запущенный в это время в QUIK'е. Я правильно понимаю? В итоге получается, что "вынести в отдельный процесс" означает по сути "переписать всю программу" на этих неизвестных мне технологиях. Думаю легче сделать по другому: написать dll, которая сама будет делать inset'ы в базу, а lua-скрипт из QUIK'а просто будет давать dll'ке нужные данные.
Пользователь
Сообщений: Регистрация: 18.09.2016
24.05.2018 09:18:44
Добрый день. Проблема скорее всего в Вашем скрипте. Использую LuaSQLite3. Читаю ТВС. Раз в полсекунды (уверен, можно и чаще) пишу новые сделки в таблицу. Далее транзакциями пишу в базу свежую порцию сделок... Итак уже полгода и по всем акциям и фьючам. База занимает 2 гига.
Пользователь
Сообщений: Регистрация: 28.09.2017
24.05.2018 09:38:39
Цитата
Сергей написал: Думаю легче сделать по другому: написать dll, которая сама будет делать inset'ы в базу,
еще проще это сделать свою структуру и писать ее lua-скриптом.
чем проще решение, тем оно стабильнее и более управляемо.
Пользователь
Сообщений: Регистрация: 10.04.2015
24.05.2018 12:15:38
Цитата
Сергей написал: Не вполне пойму, в чем противоречие.
Противоречие в том, что как вы сами пишите, когда ваш скрипт пишет в файл, то ничего не падает, а когда ваш скрипт пишет в БД, то падает. В обоих случаях Quik один и тот же, разница только в вашем коде работы с БД и в библиотеках работы с БД. Значит Quik отбрасываем. Остаются ваш код и библиотеки работы с БД. Но вы перепробовали их несколько, и падение повторилось в каждом случае. Значит их тоже отбрасываем. Остаётся только ваш код работы с БД... простой метод исключений, немного дедукции, и виновник найден... Элементарно! )))
Цитата
Сергей написал: Не очень знаком с технологиями "Protocol Buffers", "ZeroMQ", которые тут указаны. Я так понял смысл в том, что мой скрипт будет запущен обычным интерпретатором Lua и будет RPC-клиентом.
Смысл в том, чтобы вынести ваш код работы с БД в другой процесс физически. И если там ошибка, то упадёт другой процесс, а Quik останется работать вместе с LuaRPC частью. И вы убедитесь, что валится именно процесс с вашим кодом... что там внутри той же вам знать не нужно, вам лишь нужно, чтобы ваш скрипт работал в другом процессе и делал вызовы в Quik через посредника.
Пользователь
Сообщений: Регистрация: 03.03.2018
25.05.2018 11:16:10
Цитата
Suntor написал: Смысл в том, чтобы вынести ваш код работы с БД в другой процесс физически. И если там ошибка, то упадёт другой процесс, а Quik останется работать вместе с LuaRPC частью. И вы убедитесь, что валится именно процесс с вашим кодом... что там внутри той же quik-lua-rpc вам знать не нужно, вам лишь нужно, чтобы ваш скрипт работал в другом процессе и делал вызовы в Quik через посредника.
Поддерживаю!
Цитата
Сергей написал: Если записи в БД делать два раза в секунду, то падает через несколько минут.
А память сжирается процессом квика за эти несколько минут?
Пользователь
Сообщений: Регистрация: 06.04.2017
25.05.2018 12:41:03
Кажется, причина ясна.Дело оказалось вовсе не в БД, а в одновременном доступе к мапу из разных ниток. В потоке main() делалось чтение из базы и загрузка данных из нее в глобальный мап типа { "SR" = {...}, "GZ" = {...}, "RI" = {} } (то есть таблица, где ключом является не индекс, а строки). В функции обратного вызова делалось чтение из этого глобального мапа с использованием pairs(). Пока вторая нитка перебирала элементы, первая как раз в этот же момент изменила мап, и все упало. Я конечно знаю про потокобезопасные функции table.sinsert и т.д., но они только для нумерованных таблиц. Так что придется использовать что-то типа эмуляции критической секции, как описано здесь или поменять структуру данных. Сделать все в один поток не получится, потому что скрипт сложный и большой и он не только занимается работой с базой.
Пользователь
Сообщений: Регистрация: 03.03.2018
25.05.2018 21:21:27
Все же лучше смотреть в сторону отдельного процесса. Я сделал так: lua-скрипт в OnAllTrade вызывает ф-ю dll для передачи нужных параметров (практически - всех) строки таблицы всех сделок. Длл-ка в свою очередь при инициализации подключена к именованному пайп-серверу (почему-то пайпы выбрал, а не tcp/ip). А вот пайп-сервер - уже отдельно запущенное приложение со своими потоками - принимает от пайп-клиента данные, сохраняет/обрабатывает/отправляет ответ клиенту (т.е. в длл). Если длл получает ответ - вызывает коллбэк уже в квике. Работает стабильно.
Пользователь
Сообщений: Регистрация: 06.04.2017
13.06.2018 23:59:26
Продолжил работать над задачей описанной в начале темы. Поместил методы записи в базу в отдельную dll (таким образом почти полностью переписал функционал с lua на c++), к сожалению проблема осталось той же: QUIK падает через некоторое время работы. Зато теперь падает с дампом. Уважаемая тех. поддержка, куда мне нужно направить файл дампа, чтобы кто-нибудь мог посмотреть возможную причину? Так как pdb у меня нет, то символы из дампа я загрузить не могу, вижу только ошибку "Access violation reading location xxxx".
Пользователь
Сообщений: Регистрация: 23.01.2015
14.06.2018 05:12:40
Добрый день. Пришлите дамп падения на quiksupport@arqatech.com вместе со скриптом и библиотеками.
