MT5 и скорость в боевом исполнении - страница 35

Новый комментарий
 
fxsaber:

ЗадолУтомился снепшоты отлаживать. В итоге сделал идеально. Один советник - тишь и гладь. Два - замечательно. 20 - катастрофа: CPU под 100%. HistorySelect по много миллисекунд лагает.

Похоже, не предназначен MT5 для одновременной работы большого количества роботов.

Вы стресс-тест пишите или обычную работу экспертов?

Скорее всего именно многопотоковый стресс-тест в одну базу. Поэтому повторю:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

MT5 и скорость в боевом исполнении

Renat Fatkhullin, 2020.09.16 12:47

Если я правильно понял, там не советник, а стресс-тестер на каждом символе. Это совершенно меняет дело. И показывает скрытие исходных условий.

То есть, на 8(4+HT) ядерном процессоре 16 потоков (+N рабочих потоков терминала параллельно) в безостановочном режиме и без задержек ломятся в один синхронизирующийся объект базы символов. Read / Write локи перемешаны, так как постоянно идет запись тиков.

Обычно в таком профиле в зависимости от крутости процессора и его шедулера потоков, каждый поток может провести в ожидании от 60% до 80% времени.

Причем вне зависимости от типа задач.

Если по факту устраиваете в 20 потоков безостановочную битву за один ресурс, то вариантов несколько:

  1. логически развязать доступ и не заниматься стресс-тестом
  2. уйти в собственные кеши (вариант пункта 1)
  3. апгрейд железа (не обманывайтесь, что i7 2600k неплох - он плох)


Прочтите внимательно вставку. Если N потоков бьются в один синхрообъект, то пустое ожидание будет на уровне 60-80%.

И предел многопотоковой эффективности будет где-то на уровне 8-12 потоков. При увеличении количества потоков скорость выборки будет падать. На 2600k предел эффективности еще ниже.

 
Renat Fatkhullin:

Вы стресс-тест пишите или обычную работу экспертов?

Обычную

Скорее всего именно многопотоковый стресс-тест в одну базу. Поэтому повторю:

Если по факту устраиваете в 20 потоков безостановочную битву за один ресурс, то вариантов несколько:

  1. логически развязать доступ и не заниматься стресс-тестом
  2. уйти в собственные кеши (вариант пункта 1)
  3. апгрейд железа (не обманывайтесь, что i7 2600k неплох - он плох)


Прочтите внимательно вставку. Если N потоков бьются в один синхрообъект, то пустое ожидание будет на уровне 60-80%.

И предел многопотоковой эффективности будет где-то на уровне 8-12 потоков. При увеличении количества потоков скорость выборки будет падать. На 2600k предел эффективности еще ниже.

Полностью кеширую историю. Но даже для этого требуется вызывать HistorySelect(0, INT_MAX).

В качестве эксперимента порезал все нужные для торговой логики обращения к истории. Нагрузка на CPU сильно уменьшилась. 


В общем, если 20 роботов, то обращаться в них к истории - вызвать катастрофу лишь только одним Терминалом. Про несколько Терминалов даже говорить не приходится.

И такое ощущение, что синхрообъект - это не только история. SymbolInfoTick, CopyTicks и что-то еще, похоже.

В общем, у меня не получается запустить даже пять Терминалов с десятком роботов на каждом.

Посмотреть профилировщиком торможения - облом.

 
fxsaber:

Обычную

Полностью кеширую историю. Но даже для этого требуется вызывать HistorySelect(0, INT_MAX).

В качестве эксперимента порезал все нужные для торговой логики обращения к истории. Нагрузка на CPU сильно уменьшилась. 


В общем, если 20 роботов, то обращаться в них к истории - вызвать катастрофу лишь только одним Терминалом. Про несколько Терминалов даже говорить не приходится.

И такое ощущение, что синхрообъект - это не только история. SymbolInfoTick, CopyTicks и что-то еще, похоже.

В общем, у меня не получается запустить даже пять Терминалов с десятком роботов на каждом.

Посмотреть профилировщиком торможения - облом.

Нет доказательств, как и числовых данных.

1) Сколько раз в секунду каждый эксперт делает запросы HistorySelect?

2) Какие именно функции тормозят?

3) Логи?

4) Каков принцип работы роботов?

 
fxsaber:

В общем, если 20 роботов, то обращаться в них к истории - вызвать катастрофу лишь только одним Терминалом. Про несколько Терминалов даже говорить не приходится.

Может, наоборот — каждый терминал будет поддерживать свой синхрообъект, и к нему не будет очереди из 20 советников?

Попробуйте запускать 1 робота на 1 терминале, интересно посмотреть на результат.

 
Andrey Khatimlianskii:

Может, наоборот — каждый терминал будет поддерживать свой синхрообъект, и к нему не будет очереди из 20 советников?

Попробуйте запускать 1 робота на 1 терминале, интересно посмотреть на результат.

К сожалению, результат этого эксперимента не ответит на вопрос, что делать?

 
fxsaber:

К сожалению, результат этого эксперимента не ответит на вопрос, что делать?

Пересмотреть концепцию работы торгового робота

Добавлено

У меня на реале 3 терминала + 1 демо в котором работаю

В каждом терминале 42 робота, которые используют OnBoorEvent от 3-х - 4-х символов,

плюс каждые 0,5 сек. срабатывает таймер + каждый робот обращается к Глобальным переменным терминала,

при этом из 32 Гб ОЗУ используется 8,34 Гб, а ЦПУ - 6,7%

И ничего не тормозит, за исключением сервера ТМ5 в началах торговых сессий. 

 
Renat Fatkhullin:

Нет доказательств, как и числовых данных.

1) Сколько раз в секунду каждый эксперт делает запросы HistorySelect?

2) Какие именно функции тормозят?

3) Логи?

4) Каков принцип работы роботов?

Мне очень сложно ответить на эти вопросы, потому что даже я сам не могу врубиться, что тормозит. Профилировщик даже не запустить. Свои замеры обманывают, потому что лаг идет уже от CPU. Уменьшение обращения к функциями окружения через снепшоты и кеширование, к сожалению, не дали ожидаемого эффекта. Жду профилировщик, который будет в состоянии скомпилировать советник.


А пока возился, нашел вот такую гадость в Тестере с историей торгов.

void OnTick()
{
  static bool FirstRun = true;
    
  if (FirstRun)
  {
    MqlTick Tick;

    if (SymbolInfoTick(_Symbol, Tick) && Tick.ask)
    {
      MqlTradeRequest Request = {0};
      MqlTradeResult Result;
      
      Request.action = TRADE_ACTION_PENDING;
      Request.type = ORDER_TYPE_BUY_LIMIT;
      Request.symbol = _Symbol;
      Request.volume = 1;
      Request.price = Tick.ask - 10000 * _Point;

      if (OrderSend(Request, Result)) // Выставили отложку.
      {
        Request.action = TRADE_ACTION_DEAL;      
        Request.type = ORDER_TYPE_BUY;
        Request.price = Tick.ask;
        
        FirstRun = !OrderSend(Request, Result); // Открыли позицию.
      }
    }
  }

  HistorySelect(0, INT_MAX); // Результат зависит от этой строки.  
}

// Проверяет наличие ордера в истории торгов.
bool CheckTicket( const long Ticket )
{
  return(HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket);
}

#define PRINT(A) Print(#A + " = " + (string)(A))

void OnDeinit( const int )
{
  if (HistorySelect(0, INT_MAX))
  {
    PRINT(CheckTicket(4)); // true
    PRINT(CheckTicket(3)); // true
    PRINT(CheckTicket(2)); // false
  }  
}


Результат

        AUDCAD : real ticks begin from 2020.07.15 00:00:00
        2020.07.15 00:01:09   buy limit 1 AUDCAD at 0.84993 (0.94914 / 0.94993)
        2020.07.15 00:01:09   market buy 1 AUDCAD (0.94914 / 0.94993)
        2020.07.15 00:01:09   deal #2 buy 1 AUDCAD at 0.94993 done (based on order #3)
        2020.07.15 00:01:09   deal performed [#2 buy 1 AUDCAD at 0.94993]
        2020.07.15 00:01:09   order performed buy 1 at 0.94993 [#3 buy 1 AUDCAD at 0.94993]
        2020.07.15 23:59:58   position closed due end of test at 0.94646 [#3 buy 1 AUDCAD 0.94993]
        2020.07.15 23:59:58   deal #3 sell 1 AUDCAD at 0.94646 done (based on order #4)
        2020.07.15 23:59:58   deal performed [#3 sell 1 AUDCAD at 0.94646]
        2020.07.15 23:59:58   order performed sell 1 at 0.94646 [#4 sell 1 AUDCAD at 0.94646]
        2020.07.15 23:59:58   order canceled due end of test [#2 buy limit 1 AUDCAD at 0.84993]
        final balance 99999653.00 pips
        2020.07.15 23:59:58   CheckTicket(4) = true
        2020.07.15 23:59:58   CheckTicket(3) = true
        2020.07.15 23:59:58   CheckTicket(2) = false


Этот баг с трудом заметил и больше часа пытался написать воспроизведение. Код дебильный, но показывает проблему. Есть ли что-то подобное не в Тестере, а в Терминале - не знаю.

Строка для поиска: Oshibka 013.


ЗЫ b2626 - исправлено.

 
prostotrader:

Пересмотреть концепцию работы торгового робота

Только один робот, который торгует все символы?

 
fxsaber:

Только один робот, который торгует все символы?

Разные роботы, но все построены приблизительно по одной схеме.

Одновременно задействовано в одном терминале 42 работа, а на трех - 126 это около 400 символов

Добавлено

Повторюсь (у меня)

Каждый робот использует OnBoorEvent от 3-х - 4-х символов,

плюс каждые 0,5 сек. срабатывает таймер + каждый робот обращается к Глобальным переменным терминала,

при этом из 32 Гб ОЗУ используется 8,34 Гб, а ЦПУ - 6,7%

И ничего не тормозит, за исключением сервера ТМ5 (или железо Открывашки) в началах торговых сессий. 

Документация по MQL5: Основы языка / Переменные / Глобальные переменные
Документация по MQL5: Основы языка / Переменные / Глобальные переменные
  • www.mql5.com
Глобальные переменные создаются путем размещения их объявлений вне описания какой-либо функции. Глобальные переменные определяются на том же уровне, что и функции, т. е. не локальны ни в каком блоке. Область видимости глобальных переменных - вся программа, глобальные переменные доступны из всех функций, определенных в программе...
 
prostotrader:

Разные роботы, но все построены приблизительно по одной схеме.

Одновременно задействовано в одном терминале 42 работа, а на трех - 126 это около 400 символов

Добавлено

Повторюсь (у меня)

Каждый робот использует OnBoorEvent от 3-х - 4-х символов,

плюс каждые 0,5 сек. срабатывает таймер + каждый робот обращается к Глобальным переменным терминала,

при этом из 32 Гб ОЗУ используется 8,34 Гб, а ЦПУ - 6,7%

И ничего не тормозит, за исключением сервера ТМ5 (или железо Открывашки) в началах торговых сессий. 

Вот странно, у меня все наоборот.

4 терминала, уменьшил количество советников до порядка 200, все OnBook повыкидывал, перешел обратно на OnTick, обновил железо, а проблемы все те же, что и у fxsaber.

Зато тормозов по утрам в Открытии давно уже нет. А какими они были! До 75 секунд доходило порой :)

1...282930313233343536373839404142...94
Новый комментарий