Утечка памяти в CopyTicks
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Новая версия платформы MetaTrader 5 build 3180: Векторы и матрицы в MQL5 и повышение удобства работы
fxsaber, 2022.02.06 11:40
Что-то в последних билдах сделали с CopyTicksRange. Теперь при запросе больших интервалов CPU нагружается значительно меньше, но больше всего упала нагрузка на RAM - в несколько раз.
Раньше на некоторые операции не хватало свободных 10 гигов RAM. Теперь с огромным запасом. Спасибо!
Прикладываю лог 3 запусков скрипта, за каждый запуск обрабатывается по 104 символа, и скриншоты диспетчера задач
Понятнее будет, если прикрепите лог, где после каждого CopyTicks показано потребление памяти через MQL.
Предполагаю, что тики некоторое время сидят в кеше на случай повторного обращения. Кеш раздувается.
fxsaber, а как в mql5 показать съеденную терминалом память без вызовов ОС?
Проблема с CopyTicks старая, раньше была очень похожа на простую утечку, но я тогда детально не проверял повторный запрос одной и той же истории, сейчас да, похоже на кэширование истории в память, правда, почему-то после 2-го запуска объём чуть подрос, как на скринах. Но в любом случае даже обновление истории по куче тикеров (несколько тысяч) за последнюю неделю с пром. сервера брокера съедает всю память, эта "фишка" мешает.
Решил для точности копировать по 10 млн тиков, сколько есть. В первом шла догрузка с сервера, в следующих уже с диска, понятно. Логирую память в начале скрипта и на каждом шаге. На тех строчках, где скопировалось 0 тиков, а до этого - 10 млн тиков, память "проседает" где-то на 780 МБ - это накладные расходы на массив, хотя структура MqlTick должна занимать 60 байт на тик вроде бы, ну или 64. С каждым символом объём памяти растёт. Сжатые тики в tkc файлах занимают грубо 4.6 байта на тик. За весь прогон подгружается 729 млн тиков - это грубо 3300 МБ, если бы всё это кэшировалось в память. Второй прогон я запустил через 4.5 минуты после первого, строчка 108, видно, что часть памяти освободилась, но к концу 2-го, а тем более 3-го прогона память съедается всё больше и больше по сравнению с первым, возможно, и утечка есть какая, а средний пик был в районе 3800 МБ.
В общем, идеально картина вычислений не сходится, пока предположение такое, что в память из tkc разжимаются тики, также кэшируются сжатые тики, возможно, часть пережимается из-за несовпадения границ диапазонов (на что уходит CPU). Часть кэша, возможно, со временем освобождается, могут быть какие-то утечки. Но работать это всё мешает.
Как передать эту информацию тех. поддержке? Раньше был сервисдеск, теперь там шлют на форум, а какие темы читает поддержка?Я извиняюсь за вопрос - НО нафига все это - зачем вам в терминале одновременно 729 М тиков (не в файле тиков или файлах)? Вы с ними чаго делаете?
Я как -то плохо представляю задачи ML в MT5 или на столько масштабное мультивалютное тестирование.
Качать данные не раз в неделю, а раз в день или сессию не пробовали? или ежечасно?
Перегружать и запускать терминал автоматически?
Я даже представить себе боюсь - когда вы осознаете что брокеров может быть не один или всерьез займетесь арбитражом. и 1000 инструментов начнется восприниматься как ясельная группа.
Упоротый юзер - страшный сон разработчика, мог ли он (разработчик) представить - что его программу будут использовать для жесткого DDos брокера (40-50Гб в час - это жестко, могут быть последствия со стороны брокера, и я так понимаю, вы этим не собираетесь ограничиваться).
"Фишка" - это у кого надо фишка, она для того и придумана, что бы не досить брокеров, и ускорять работу терминала.
Крамольные мысли от другого упоротого юзера:
а что если сменить счет в открытом терминале, тип сервера, брокера - кеш очищается? надо будет когда-нибудь проверить, если будет не лень или не забуду.
Я извиняюсь за вопрос - НО нафига все это - зачем вам в терминале одновременно 729 М тиков (не в файле тиков или файлах)? Вы с ними чаго делаете?
Именно что в файлах истории мне они и нужны, а не в памяти, куда их накапливает терминал, причём все сразу. Какой ещё ДдОС брокера? История, во-первых, сохраняется в файлах tkc, посмотрите в логах скорость первого и второго запусков. А память засоряется даже если просто из файлов tkc запрашиваешь тики, например, в Питон, и хочешь сохранить в свой формат. Формат tkc закрытый. Извращаться и автоматически закрывать/открывать терминал - плохая затея. И раньше, кстати, не было функции CopyTicksRange с чётким ограничением по датам, и раньше память засорялась куда быстрее. А 1000 инструментов легко - одна серия опционов по паре акций. А акций много.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Здравствуйте. Проблема присутствует в последнем билде 3211 и в более ранних. Если копировать историю по небольшому списку символов или на небольшую глубину, это не бросается в глаза, но если попытаться запросить историю по всем символам, которые даёт брокер (особенно, если это пром. сервер и символов много: акции / деривативы), и на всю глубину, терминал довольно быстро начинает съедать под 20 ГБ памяти, его приходится закрывать и продолжать копирование со следующих символов.
Для воспроизведения проблемы прикладываю скрипт, основа взята из примера в справке по функции CopyTicks, в скрипте для удобства я добавил переключение между CopyTicks и CopyTicksRange с переменной use_range (утечка есть в обеих функциях). Глубина для примера - с прошлого октября. Запускаю на билде 3211 терминала, скачанного с сайта metatrader5.com, сервер по умолчанию - MetaQuotes-Demo. Прикладываю лог 3 запусков скрипта, за каждый запуск обрабатывается по 104 символа, и скриншоты диспетчера задач ДО запуска скрипта, после первого и второго (суффиксы 0, 1 и 2 соответственно). Как видно, потребление за один запуск выросло с 357 до 1836 МБ, после второго - 2211. После третьего запуска потребление памяти почти не увеличивается. Если увеличить глубину запрашиваемой истории и заново запустить скрипт, потребление памяти вырастет. На пром. серверах с тысячами символов, как я уже сказал, потребление вырастает до таких размеров, что приходится загружать историю порциями по N символов и постоянно перегружать терминал.
Если вызывать copy_ticks_range из Питона, всё равно неконтролируемо растёт потребление памяти в терминале.