Ошибки синхронизации в облаке - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Привет, Стринго,
Во-первых, спасибо за информацию.
Однако, меня интересует аргументация MetaQuotes по этому поводу. Если используется большое количество данных "каждый тик" (например, 2003.1.1 -> 2013.1.1) и оптимизируемый эксперт достаточно сложен, то на одну итерацию оптимизации часто уходит больше 10 минут. Есть ли какая-то конкретная причина, по которой MetaQuotes выбрала период в 10 минут в качестве тайм-аута? Кроме того, есть ли способ для пользователя облака увеличить этот тайм-аут или это "жестко запрограммировано" MetaQuotes?
Бесконечный цикл обнаружен только на облачных агентах. Если один из вызовов(OnInit, OnDeinit, OnTick, OnTimer и т.д.) работает более 10 мин.
Это не одиночная оптимизация, это вызов сигнала к функции.
Ах - моя ошибка - я почему-то решил, что речь идет об одной итерации оптимизации, а не об одном вызове обработчика событий (хотя Стринго специально упомянул один вызов обработчика событий). Один вызов обработчика событий, который длится более 10 минут, был бы действительно нелепым.Мои скромные извинения - должно быть, у меня было затуманивание мозгов - пора отдохнуть :).
Ммммм - значит, должно быть что-то странное происходит в моем Эксперте, что заставляет OnTick() иногда занимать более 10 минут для завершения вызова. Пора начинать копать...
В любом случае, еще раз спасибо за помощь, ребята!
Это не одна оптимизация, это вызов сигнала к функции.
Привет,
Все еще копаюсь, но не могу ничего найти. Тот факт, что мой эксперт безупречно оптимизируется на моих локальных агентах (т.е. ни один из процентов прогресса моих агентов не приостанавливается и не останавливается в любое время, что, как я мог бы предположить, произошло бы, если бы в моей функции OnTick() был какой-то бесконечный цикл, который длился бы по крайней мере 10 минут или больше), действительно затрудняет дело.
Мне интересно одно - на что указывает номер PR в конце сообщения об ошибке (например, ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)"). Может ли кто-нибудь пролить свет на это?
Заранее спасибо за помощь.
Привет,
Все еще копаюсь, но не могу ничего найти. Тот факт, что мой эксперт безупречно оптимизируется на моих локальных агентах (т.е. ни один из процентов прогресса моих агентов не приостанавливается и не останавливается в любое время, что, как я мог бы предположить, произошло бы, если бы в моей функции OnTick() был какой-то бесконечный цикл, который длился бы по крайней мере 10 минут или больше), действительно затрудняет дело.
Мне интересно одно - на что указывает номер PR в конце сообщения об ошибке (например, ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)"). Может ли кто-нибудь пролить свет на это?
Заранее благодарю за помощь.
Более подробную информацию см. здесь.
Здравствуйте,
Проведя много часов на выходных за изучением своего кода, я не смог найти ни одного места в коде моего Эксперта, где могла бы возникнуть возможность бесконечного цикла. И в процессе работы я также все больше и больше убеждался, что если бы у моего Эксперта были проблемы с бесконечным циклом, я должен был бы увидеть, что это стало очевидным при использовании моих локальных агентов для оптимизации моего Эксперта. Как я уже упоминал выше, мои локальные агенты не делают паузы ни на одном этапе оптимизации моего Эксперта, не говоря уже о десяти минутах или более.
После того, как я убедился, что проблемы возникли не из-за моего Эксперта, я начал рассматривать другие альтернативы. Единственной логичной альтернативой, которую я мог видеть, было то, что проблемы были либо с самими агентами (т.е. ошибки), либо с коробками, на которых они работали. Похоже, что виновником является вторая из этих альтернатив.
Насколько я могу судить, люди запускают облачные агенты на самых разных коробках. Я также предполагаю, что все эти облачные агенты работают на базе Windows. Я упоминаю об этом потому, что мой личный опыт использования потребительских версий Windows показывает, что они печально известны своей нестабильностью при длительной работе, склонностью замедляться или даже выходить из строя при серьезных требованиях к обработке данных.
Оптимизация, которую я пытался выполнить, касалась достаточно сложного эксперта, работающего с данными за 6-7 лет"каждый тик" - т.е. требующего разумных требований к обработке и памяти. Я подозревал, что агенты в облаке, берущие на себя эту задачу, недостаточно специфицированы - особенно если учесть, что они будут работать под управлением Windows.
Поэтому я поместил следующую строку кода в обработчик события OnInit():
Причина, по которой я использовал TERMINAL_MEMORY_PHYSICAL, заключается в том, что другие опции памяти:TERMINAL_MEMORY_TOTAL и TERMINAL_MEMORY_AVAILABLE не слишком полезны, поскольку они предоставляют вам только общее виртуальное адресное пространство пользовательского режима процессора хоста (т.е. 4 ГБ для 32-битного процессора или 8 ТБ для 64-битного процессора). Я не могу представить себе 64-битные машины с 8 ТБ памяти - по крайней мере, пока. :) TERMINAL_CPU_CORES был еще одним параметром, который я рассматривал, но в конце концов решил просто протестировать память, поскольку я предполагаю, что любая машина с приличным количеством памяти будет иметь приличные характеристики во всех остальных важных областях.
И знаете что - больше никаких проблем! Все мои оптимизации теперь работают нормально. :)
Здравствуйте,
Проведя много часов на выходных за изучением своего кода, я не смог найти ни одного места в коде моего Эксперта, где могла бы возникнуть возможность бесконечного цикла. И в процессе работы я также все больше и больше убеждался, что если бы у моего Эксперта были проблемы с бесконечным циклом, я должен был бы увидеть, что это стало очевидным при использовании моих локальных агентов для оптимизации моего Эксперта. Как я уже упоминал выше, мои локальные агенты не делают паузы ни на одном этапе оптимизации моего Эксперта, не говоря уже о десяти минутах или более.
После того, как я убедился, что проблемы возникли не из-за моего Эксперта, я начал рассматривать другие альтернативы. Единственной логичной альтернативой, которую я мог видеть, было то, что проблемы были либо с самими агентами (т.е. ошибки), либо с коробками, на которых они работали. Похоже, что виновником является вторая из этих альтернатив.
Насколько я могу судить, люди запускают облачные агенты на самых разных компьютерах. Я также предполагаю, что все эти облачные агенты работают на базе Windows. Я упоминаю об этом потому, что мой личный опыт использования потребительских версий Windows показывает, что они печально известны своей нестабильностью при длительной работе, склонностью замедляться или даже выходить из строя при серьезных требованиях к обработке данных.
Оптимизация, которую я пытался выполнить, касалась достаточно сложного эксперта, работающего с данными за 6-7 лет "каждый тик" - т.е. требующего разумных требований к обработке и памяти. Я подозревал, что агенты в облаке, берущие на себя эту задачу, недостаточно специфицированы - особенно учитывая, что это будут коробки с Windows.
Поэтому я поместил следующую строку кода в обработчик события OnInit():
Причина, по которой я использовал TERMINAL_MEMORY_PHYSICAL, заключается в том, что другие опции памяти:TERMINAL_MEMORY_TOTAL и TERMINAL_MEMORY_AVAILABLE не слишком полезны, поскольку они предоставляют вам только общее виртуальное адресное пространство процессора хоста в пользовательском режиме (т.е. 4GB для 32-битного процессора или 8TB для 64-битного). Я не могу представить себе 64-битные машины с 8 ТБ памяти - по крайней мере, пока. :) TERMINAL_CPU_CORES был еще одним параметром, который я рассматривал, но в конце концов решил просто протестировать память, поскольку я предполагаю, что любая машина с приличным количеством памяти будет иметь приличные характеристики во всех остальных важных областях.
И знаете что - больше никаких проблем! Все мои оптимизации теперь работают нормально. :)
Это звучит как отличная идея, и я благодарен за эту подсказку.
Однако, 3 вещи по этому поводу:
1) Как я уже говорил выше, у меня тоже есть проблема "бесконечного" цикла, но поскольку я понял из этой темы, что "бесконечный цикл" - это просто лучшее предположение для "одно событие заняло больше десяти минут", я допускаю, что дело может быть в моем коде. Я использую довольно сложные индикаторы, и поскольку (по крайней мере, я так думаю) они рассчитывают всю свою историю при создании хэндла, это может занять (на медленных компьютерах) более десяти минут.
2) Однако! Обычно мое облако падало через 10-15 минут. Но вчера вечером оно прекрасно работало в течение 8 часов. Ни одного сбоя, хотя я вообще не менял код. Странно!
3) И самое важное, потому что это связано с вашим подходом: Когда вы отвергаете агента на основе его памяти, агент (а за ним и все облако) не падает, я это понимаю. Но я не думаю, что более мощная машина будет пытаться повторить тот же набор параметров, так что вы, по сути, теряете точки данных оптимизации, я прав? Вы бы сказали, что это цена, которую нам придется заплатить?
Будет любопытно посмотреть, будут ли мои агенты по-прежнему работать, когда я вернусь с работы...
...