Ошибки синхронизации в облаке - страница 3

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

Это звучит как отличная идея, и я благодарен за эту подсказку.

Однако, 3 вещи по этому поводу:

1) Как я упоминал выше, у меня тоже есть проблема "бесконечного" цикла, но поскольку я понял из этой темы, что "бесконечный цикл" - это просто лучшее предположение для "одно событие заняло больше десяти минут", я допускаю, что это может быть мой код. Я использую довольно сложные индикаторы, и поскольку (по крайней мере, я так думаю) они рассчитывают всю свою историю при создании хэндла, это может занять (на медленных компьютерах) более десяти минут.

2) Однако! Обычно мое облако падало через 10-15 минут. Но вчера вечером оно прекрасно работало в течение 8 часов. Ни одного сбоя, хотя я вообще не менял код. Странно!

3) И самое важное, потому что это связано с вашим подходом: Когда вы отвергаете агента на основе его памяти, агент (а за ним и все облако) не падает, я это понимаю. Но я не думаю, что более мощная машина будет пытаться повторить тот же набор параметров, так что вы, по сути, теряете точки данных оптимизации, я прав? Вы бы сказали, что это цена, которую нам придется заплатить?


Будет любопытно посмотреть, будут ли мои агенты работать, когда я вернусь с работы...

Привет, Клок,

1) Во-первых, если вы не используете индикаторы, скажем, на 10-летних данных размером 1 млн. и индикаторы невероятно сложны, я был бы очень удивлен, что в наше время вычислительной мощности на НОРМАЛЬНОЙ системе на все уйдет даже 5 минут. Причина, по которой я подчеркиваю "нормальной", заключается в том, что я все еще подозреваю, что в облаке есть ряд агентов, работающих на машинах, которые либо очень загружены, либо просто имеют тяжелый случай замедления работы Windows (посттравматический стресс). И достаточно одного неудачного агента, чтобы убить вашу оптимизацию.....

2) У меня было точно так же, как у вас - т.е. после запуска оптимизации несколько облачных агентов выдавали результаты без каких-либо проблем. Затем через 5-20 минут, а иногда и дольше, агент выдавал страшную ошибку и БАНГ - конец оптимизации. Кроме того, иногда оптимизация завершалась без проблем. Это очень расстраивает, поскольку у вас нет никакого доступа к лог-файлам агентов, деталям системы, использованию процессора и т.д., чтобы понять, что происходит.

3) Это очень интересное замечание. Насколько я понимаю, оптимизатор считает определенную комбинацию параметров "использованной" только тогда, когда он получил результаты для этой конкретной комбинации параметров, хотя я могу ошибаться. Возможно, кто-то из MetaQuotes может прокомментировать этот момент?

В любом случае, я надеюсь, что у вас есть успехи! :)

 
angevoyageur:
Сколько агентов доступно, когда вы отбрасываете всех , у кого меньше 32 Гб оперативной памяти?

Здравствуйте,

Это действительно кажется большим объемом оперативной памяти для ПК потребительского типа, но облако, похоже, не испытывает проблем с поиском машин с такими характеристиками. Когда я начинаю оптимизацию, оптимизатор легко находит начальные 64 агента, а затем довольно быстро увеличивает до 128 (в зависимости от конфигурации набора параметров, конечно). Сначала я попробовал 8 ГБ - оптимизация выполнялась дольше и часто завершалась, но все равно регулярно агент выдавал ошибку и, как следствие, завершал оптимизацию. Затем я попробовал 16 ГБ - снова стало лучше, но не безупречно. Я не стал пробовать 24 ГБ - решил сразу перейти на 32 ГБ и посмотреть, что получится :). И вуаля - безупречная оптимизация.

Я хотел еще поиграть и посмотреть, смогу ли я немного улучшить требования к конфигурации агентов, но когда с вас берут деньги за игру, стимул быстро пропадает. :)

 
cowil:

Здравствуйте,

Это действительно кажется большим объемом оперативной памяти для ПК потребительского типа, но облако, похоже, не испытывает проблем с поиском машин с такими характеристиками. Когда я начинаю оптимизацию, оптимизатор легко находит начальные 64 агента, а затем довольно быстро увеличивает объем до 128 (конечно, в зависимости от конфигурации набора параметров). Сначала я попробовал 8 ГБ - оптимизация выполнялась дольше и часто завершалась, но все равно регулярно агент выдавал ошибку и, как следствие, завершал оптимизацию. Затем я попробовал 16 ГБ - снова стало лучше, но не безупречно. Я не стал пробовать 24 ГБ - решил сразу перейти на 32 ГБ и посмотреть, что получится :). И вуаля - безупречная оптимизация.

Я хотел еще поиграть и посмотреть, смогу ли я немного улучшить требования к конфигурации агента, но когда с вас берут деньги за игру, стимул быстро исчезает. :)

Было бы интересно получить некоторую отдачу от Metaquotes. Если машины с 16G ram недостаточно для запуска оптимизации, то есть повод для расследования. Если я правильно понял, когда вы запускаете оптимизацию локально, у вас нет никаких проблем, почему тогда при использовании облака требуется так много памяти?
 
angevoyageur:
Было бы интересно получить ответ от Metaquotes. Если машина с 16G ram недостаточна для запуска оптимизации, есть повод для расследования. Если я правильно понял, когда вы запускаете оптимизацию локально, у вас нет никаких проблем, почему тогда при использовании облака требуется так много памяти?

У меня нет абсолютно никаких идей. Моя локальная машина - это машина с 8 ГБ процессором i7, на которой MT5 установил 8 локальных агентов (очевидно, что это только 4-ядерный процессор, но с Hyper-Threading, Windows и, следовательно, MT5 видят его, конечно, как 8-ядерный процессор). Когда выполняется оптимизация, агенты используют около 400 МБ памяти каждый, что, очевидно, составляет около 3,2 ГБ необходимой памяти для 8 агентов. Никуда не годится 32 ГБ....

Еще одна вещь, о которой я подумал, и которая на самом деле может быть первопричиной этой проблемы, это тот факт, что один "плохой" агент облака прекращает всю оптимизацию. Возможно, на самом деле происходит то, что когда облачный сервер выделяет агентов для задания оптимизации (без указания требований к памяти), выбирается один и тот же "плохой" агент(ы). Когда требования к памяти указываются в OnInit(), "плохие" агенты обходятся стороной, поскольку ящики, на которых они работают, не соответствуют требованиям, и выбираются только хорошие агенты. Думая об этом, я подозреваю, что это, вероятно, более правильный вариант.

И да, я зарегистрировал этот вопрос в MetaQuotes, но пока ничего не получил в ответ.

 

Если OnInit (или любая другая функция) выполняется более 10 минут даже на медленном агенте, это считается бесконечным циклом, вредным для MQL5 Cloud Network (обратите внимание, что для локальных и удаленных агентов такого ограничения нет).

Для подобных ситуаций мы реализовали код возврата INIT_AGENT_NOT_SUITABLE для функции OnInit. Используя его, пользователь облачной сети может проверить и отклонить неподходящие агенты в самом начале тестового запуска.

Вы можете рассматривать этот комментарий как официальный ответ на ваш тикет Service Desk. Мы знаем, что вы ознакомлены с приведенной выше информацией.

Кроме того: В любом случае, любая функция считается ненормальной, неэффективной и неоптимальной, если ее выполнение занимает более 10 минут даже на самом медленном ПК.

 
MetaQuotes:

Если OnInit (или любая другая функция) выполняется более 10 минут даже на медленном агенте, это считается бесконечным циклом, вредным для MQL5 Cloud Network (обратите внимание, что для локальных и удаленных агентов такого ограничения нет).

Для подобных ситуаций мы реализовали код возврата INIT_AGENT_NOT_SUITABLE для функции OnInit. Используя его, пользователь облачной сети может проверить и отклонить неподходящие агенты в самом начале тестового запуска.

Вы можете рассматривать этот комментарий как официальный ответ на ваш тикет Service Desk. Мы знаем, что вы ознакомлены с приведенной выше информацией.

Кроме того: В любом случае, любая функция считается ненормальной, неэффективной и неоптимальной, если ее выполнение занимает более 10 минут даже на самом медленном ПК.

Здравствуйте, MetaQuotes,

Во-первых, большое спасибо за ваши комментарии - очень ценю.

Проблема, с которой я столкнулся (и другие, очевидно, если вы посмотрите назад на это сообщение), заключается в том, что когда оптимизация выполняется с помощью моих локальных агентов, оптимизация проходит нормально - т.е. статус "процент завершения" на каждом агенте постоянно увеличивается по мере выполнения оптимизации. Если бы обработчик события OnTick() в моем Expert содержал какой-либо код, на выполнение которого потребовалось бы больше минуты (не говоря уже о 10 минутах), то, конечно, эти проценты "процент выполнения" приостанавливались бы в это время? Не должен ли я видеть паузы в 10 минут (или более) в этих процентах статуса, если мой код содержит формы бесконечного цикла, на которые указывают ошибки облачного агента?

 

Ну, после многих часов работы над моим экспертом, похоже, что я нашел источник проблем с ошибками "бесконечного цикла" OnInit() или OnTick() - это команда SymbolInfoInteger(). Я не знаю, вызывают ли SymbolInfoDouble() или SymbolInfoTick() те же проблемы, поскольку у меня еще не было возможности экспериментировать дальше. Если кто-то хочет проверить это, запустите в Оптимизаторе следующий Эксперт, используя облачных агентов:

/+------------------------------------------------------------------+
//|                                              MultiSymbolTest.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
input double var1 = 45;
input double var2 = 54;

input bool onInit = true;
input bool onTick = false;


//+------------------------------------------------------------------+
//| expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit() { 

    
    if (onInit) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return(INIT_FAILED);
        }
    }           

    // Return...
    return(INIT_SUCCEEDED);
}



//+------------------------------------------------------------------+
//| expert start function                                            |
//+------------------------------------------------------------------+
void OnTick() {

    if (onTick) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return;
        }
    }           

    ExpertRemove();
}    

Выберите, хотите ли вы протестировать OnInit() или OnTick(), задайте var1 и var2 достаточные значения start/step/stop, чтобы сгенерировать около 1000 комбинаций (возможно, подойдет и меньше, но я использовал именно это) и запустите оптимизатор. Примерно через 10 минут вы увидите ошибку "обнаружен бесконечный цикл".

О, и причина, по которой я поместил "ExpertRemove()" в конец OnTick(), заключается в том, чтобы показать, что для возникновения ошибки требуется только одна итерация OnTick().

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

 
О, и я забыл упомянуть, что по какой-то причине исправление памяти, которое я предоставил выше, похоже, устраняет проблему в большинстве случаев, но не во всех. Как/почему/что это работает, я не знаю. Должно быть, это щекочет что-то в недрах MT5... :)
 

Я могу подтвердить эту проблему:

2013.05.20 14:22:31 MQL5 Cloud Europe 2 генетический проход (0, 22) протестирован с ошибкой "endless loop detected in OnInit function, expert rejected by MQL5 Cloud Network" in 602 sec (PR 140)

 
Нужно подумать...
12345
Новый комментарий