![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Уважаемые разработчики, могли бы Вы сообщить, как вычисляется MQL_MEMORY_USED?
Сделал расчет памяти, что занимают все переменные советника.
Это меньше 10%. Если правильно понимаю, то в MQL_MEMORY_USED входит History-кеш и CopyTicks-кеш. Но это все равно значительно меньше должно занимать.
При этом параллельный советник кушает в несколько раз меньше. Хотя принцип тот же.
В общем, что входит в это значение?
ЗЫ Сохранил шаблон с советником и к этому же чарту применил, вызвав перезагрузку. Стало так.
Потребление памяти изменилось почти на порядок. Сложно пока объяснить, что это обозначает.
Накопительный эффект пользования памяти есть у многих прог. Этим браузеры грешат, тот же ворд, иногда может. Терминал тоже грешит. К тому же логи по дефолту пишут все и если много действий то в гиг за неделю легко улететь. Это зло, которым надо управлять. Правда не понятно как.
Может быть Вы знаете как программно выбрать финансовый инструмент и не зависнуть на века ?
Через индикатор
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
MT5 и скорость в боевом исполнении
Renat Fatkhullin, 2020.10.14 04:15
Для массовой работы с тиками ставьте больше памяти.
4 гб (цена 20 евро) - это никуда не годится в 2020 году, если речь идет об аналитике и исследованиях.
Для Маркет-продуктов такой подход никуда не годится. Приходится обходить 10-ти секундное удержание в памяти ненужных данных через такой костыль.
Сделать тривиальный Маркет-продукт в виде Маркет-скринера - фактически, не посильная задача для MT5 из-за чрезмерного расхода памяти.
Сделать тривиальный Маркет-продукт в виде Маркет-скринера - фактически, не посильная задача для MT5 из-за чрезмерного расхода памяти.
Терминал после запуска съедает столько памяти.
После выполнение скринера стал съедать 2 гига (TERMINAL_MEMORY_USED и не уменьшалось со временем). Это при только одном открытом чарте на 5000 M1-баров.
Скрин не сохранил. Но решил накидать пример, показывающий, выжирание памяти Терминалом не в себя там, где это просто глупо.
Скрипт просто делает копии оригинальных символов из Обзора рынка. Предполагалось, что на MQ-Demo добавлю все символы и запущу этот скрипт первый раз на холодную, а потом повторно - на горячую.
И после горячего (когда тики уже на SSD в виде tkc-файлов) запуска буду наблюдать дикое выжирание памяти там, где это совсем не нужно при должной реализации.
Однако, запустив скрипт, столкнулся с тем, что он подвисает на MQ-Demo. Снимается только через Abnormal termination, после чего Терминал не высвобождает больше 1 Гб памяти.
Легко сравнить этот скрин с тем, что в начале.
Простите, не уверен баг это или фича. Самостоятельно ответа не нашел. Но вопрос связан по поводу производительности и полагаю, что лучше этот вопрос задать тут.
Если в пустой индикатор добавить, скажем, 22 буфера с типом DRAW_SECTION, то при запуске такого индикатора на одном чарте, в котором находится 1000000 баров и выше, то терминал начинает достаточно сильно тормозить (так же идет заметная нагрузка на ЦП) и съедать заметное количество оперативной памяти, даже если индикатор ничего не вычисляет.
Мой интерес вызвал тот факт, что если использовать буферы с другими типами, то все работает без проблем и подобного замедления не наблюдается.
К примеру, я запускал следующий код индикатора на единственном чарте в котором содержится 1000000 баров и терминал съедал около 500 МБайт и заметно лагал, особенно сам чарт.
Но если поменять тип буфферов на, скажем, DRAW_LINE, то нагрузка на процессор резко понижается, лагов не наблюдается, а оперативка съедается в 5 раз меньше (потребляется около 100 МБайт).
Подобные тесты проводил на разных билдах, вплоть до билдов 2019 года и ситуация одинаковая.
Отдельный гражданин достал из широких штанин дубликатом бесценного груза MQL-код, который показал, что в одних и тех же условиях костыль работает быстрее штатной функции.
Очень простой тест:
20 экспертов на EURUSD, т.е. все OnTick процессим одновременно. Билд терминала 2664. Запускать тест без оптимизации, компиляции и проч. доп.загрузки на 100% цпу - вы же не собираетесь запускать реальную "hft" торговлю на таком фоне?
Типичный лога теста:
Очень простой тест:
20 экспертов на EURUSD, т.е. все OnTick процессим одновременно. Билд терминала 2664. Запускать тест без оптимизации, компиляции и проч. доп.загрузки на 100% цпу - вы же не собираетесь запускать реальную "hft" торговлю на таком фоне?
Типичный лога теста:
Вы создаете тепличные условия, делая 100К итераций в течение 1.5 секунд на одном и том же тике. Я же специально дожидался тиков, которые не породили OnTick.
Просматривая логи своей торговли, замечаю исполнение SymbolInfoTick в течение нескольких миллисекунд. При этом на 100% знаю, что в этот момент был полный Idle CPU.
Все очень просто. В сутки условно 1 млн тиков. Даже тормоза в 0.01% тиков - 100 тиков в сутки с лагами. Вы скажете, что это ерунда. Я - плохо. Если нарвусь на лаг, когда нужно делать приказ, то это потенциальные денежные потери.
Очень благодарен, что эта ветка не остается незамеченной, и по этой функции, в частности, сделана большая работа по ускорению. Однако, для меня было несколько неожиданным, что ужасный костыль в определенных ситуациях может опережать штатную функцию. И, возможно, если бы Вы разобрались и устранили это отставание, то 100 потенциальных лагов в сутки превратились бы в 10.
Говорю, что стало много лучше, чем в начале ветки. Но факт остается фактом - есть моменты, когда нехорошо. И вижу, что Вы не хотите в этом разбираться. Уважаю Ваш выбор.
Выше приводил снепшотовый вариант получения текущих цен. Он меня бы полностью устроил, если бы не ловил на Idle-CPU машине миллисекундные лаги.
Меня также волнует вопрос не только скорости SymbolInfoTick, но и актуальности отданных ею цен. Вижу, что Вы этот вопрос не поднимаете. Видимо, решили позже посмотреть.
Вы создаете тепличные условия, делая 100К итераций в течение 1.5 секунд на одном и том же тике. Я же специально дожидался тиков, которые не породили OnTick.
Просматривая логи своей торговли, замечаю исполнение SymbolInfoTick в течение нескольких миллисекунд. При этом на 100% знаю, что в этот момент был полный Idle CPU.Все очень просто. В сутки условно 1 млн тиков. Даже тормоза в 0.01% тиков - 100 тиков в сутки с лагами. Вы скажете, что это ерунда. Я - плохо. Если нарвусь на лаг, когда нужно делать приказ, то это потенциальные денежные потери.
Очень благодарен, что эта ветка не остается незамеченной, и по этой функции, в частности, сделана большая работа по ускорению. Однако, для меня было несколько неожиданным, что ужасный костыль в определенных ситуациях может опережать штатную функцию. И, возможно, если бы Вы разобрались и устранили это отставание, то 100 потенциальных лагов в сутки превратились бы в 10.
Говорю, что стало много лучше, чем в начале ветки. Но факт остается фактом - есть моменты, когда нехорошо. И вижу, что Вы не хотите в этом разбираться. Уважаю Ваш выбор.
Выше приводил снепшотовый вариант получения текущих цен. Он меня бы полностью устроил, если бы не ловил на Idle-CPU машине миллисекундные лаги.
Меня также волнует вопрос не только скорости SymbolInfoTick, но и актуальности отданных ею цен. Вижу, что Вы этот вопрос не поднимаете. Видимо, решили позже посмотреть.
Это совершенно не тепличные условия. Цикл на 100000 запросов цены без Sleep() и тому подобного и в 20 потоков одновременно - очевидный стресс тест. Ничего подобного в реальных условиях даже близко быть не должно.
Если вы думаете, что за 1.5 секунды не приходят другие тики - ок, сделайте 10 миллионов запросов, это ничего не поменяет, ваш "костыль" работает хуже:Вот это ваше утверждение на 100% ложное:
Как и вот это ваше предыдущее утверждение:
Доступ к ценам через SymbolInfoTick сейчас очень быстрый и он полностью отвязан от процессинга потока тиков. Вы работаете с готовым кэшем цен, который обновляется очень экономно и быстро.
Все "тормоза в 0.01% тиков" проявляются только в условиях стресс-теста, и это отличный результат. В нормальных условиях доступ гарантированно очень быстрый.
Если вы признаёте, что "сделана большая работа по ускорению" SymbolInfoTick, то вам следуют мне поверить, что "костыль" с получением цен через PositionSelectByTicket не может быть лучшим решением.
По одной простой причине - реализация PositionSelectByTicket полностью идентична первоначальной "медленной" реализации SymbolInfoTick.
Как я писал выше, эта реализация не является медленной в прямом смысле этого слова, но при большой нагрузке на цпу, имеет более высокую вероятность выбросов по времени выполнения (что хорошо видно в моем последнем тесте).
Тут тайминги сильно зависят от работы планировщика задач системы под нагрузкой, т.е. могут быть различия в разных ОС и даже их версиях.
И чем больше нагрузка, тем больше вы тестируете эффективность работы планировщика задач, а не терминала.
На этом тему быстродействия SymbolInfoTick закрываю.
Если ваши эксперты создают нагрузку на уровне синтетических стресс-тестов, то решение одно: "железо должно соответствовать задачам".
У меня вопрос про актуальность тиков, которые отдает SymbolInfoTick.
Ситуация:
1. Делаем TimeCurretn(); получаем время 18:00:00
2. Делаем SymbolInfoTick по нелеквидному символу. Получаем тик со временем 17:58:00.
3. Sleep(1)
4. Делаем SymbolInfoTick по нелеквидному символу. Получаем тик со временем 17:59:00.
Т.е четвертом пункте мы получили новый тик, который на минуту отличается TimeCurretn().
Видите ли вы проблему в данной ситуации ?
Как в такую ситуацию попадать по реже ?
У меня вопрос про актуальность тиков, которые отдает SymbolInfoTick.
Ситуация:
1. Делаем TimeCurretn(); получаем время 18:00:00
2. Делаем SymbolInfoTick по нелеквидному символу. Получаем тик со временем 17:58:00.
3. Sleep(1)
4. Делаем SymbolInfoTick по нелеквидному символу. Получаем тик со временем 17:59:00.
Т.е четвертом пункте мы получили новый тик, который на минуту отличается TimeCurretn().
Видите ли вы проблему в данной ситуации ?
Как в такую ситуацию попадать по реже ?
SymbolInfoTick отдает данные, полученные от сервера брокера. Что сервер прислал, то вы и получаете.
Если есть вопросы по тиковому потоку, который транслирует ваш брокер, то и обращаться надо к вашему брокеру.