Вопрос разработчикам - использование всех вычислительных ядер при оптимизации - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Интересный подход.
может быть несколько решений этой задачи в зависимости от специфики.
если у всех параметров, тех которые уже есть и тех которые могут появится, будет строго определённое место в наборе параметров (хромосома или иной другой эквивалент), тогда вообще проблем нет.
если определённое место каждого параметра не может быть определено заранее, то нужно разделить параметры на типы, которые можно комбинировать строго только друг с другом (тогда не имеет значения на каком месте находится параметр) - потребуется модификация АО.
есть ещё другие варианты решения задачи, но потребуется в любом случае кастомный АО, надстройка над штатным.
подтвердилась инфа о перегрузке памяти .... хотя странно, swap никто не отменял, опять же думаю разработчикам надо это учесть
Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.
Сколько минимально памяти нужно на одного агента (уменьшали количество активированных, пока все не стали нагружаться равномерно?)
Увеличили pagefile? При этом физическая память будет постоянно свопиться, возможно сильное замедление, надо найти такое количество ядер, когда общее время оптимизации минимально.
Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.
Сколько минимально памяти нужно на одного агента (уменьшали количество активированных, пока все не стали нагружаться равномерно?)
Увеличили pagefile? При этом физическая память будет постоянно свопиться, возможно сильное замедление, надо найти такое количество ядер, когда общее время оптимизации минимально.
Это всё зависит от использования тиков, глубины истории, количества инструментов. Просто смотрите в диспетчер задач, там всё видно, объём всей оперативки минус 1-2 Гб для операционки деленное на используемый объём одним агентом. У каждого всё индивидуально.
Реально улучшить ситуацию могут разработчики, если для котировок и, возможно, для индикаторов будет использоваться одна область оперативной памяти.Это всё зависит от использования тиков, глубины истории, количества инструментов. Просто смотрите в диспетчер задач, там всё видно, объём всей оперативки минус 1-2 Гб для операционки деленное на используемый объём одним агентом. У каждого всё индивидуально.
Реально улучшить ситуацию могут разработчики, если для котировок и, возможно, для индикаторов будет использоваться одна область оперативной памяти.Мне объясняете? Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет.
А неэффективное использование памяти терминалом мы уже много раз обсуждали, да и MQ несколько раз обещала изменить ситуацию с дублированием истории тиков и временных файлов для каждого агента, и их длительным созданием перед каждой тиковой оптимизацией. Лично мне приходится отключать почти половину агентов и тиковой оптимизации за несколько лет. У меня 8Гб и 8 агентов. Но пока пользуемся тем, что есть, а мы можем либо увеличивать размер памяти, либо отключать агентов.
Мне объясняете? Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет.
А неэффективное использование памяти терминалом мы уже много раз обсуждали, да и MQ несколько раз обещала изменить ситуацию с дублированием истории тиков и временных файлов для каждого агента, и их длительным созданием перед каждой тиковой оптимизацией. Лично мне приходится отключать почти половину агентов и тиковой оптимизации за несколько лет. У меня 8Гб и 8 агентов. Но пока пользуемся тем, что есть, а мы можем либо увеличивать размер памяти, либо отключать агентов.
>Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.
>Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет.
Прошу прощения, работал, было некогда.
Провел оптимизацию советника. Убрал некоторые "неважные" части ради того чтобы оптимизатор начал работать (а конкретно все что связано с OpenCL и SQLite). Теперь у меня нет переполнения памяти. НО ... это не решение конечно.
На другом пк чтобы не уходил в зависание просто пришлось отключить часть ядер ... так например система на 3950Х (16 ядер/32 потока) и 32 Гб - при использовании всех потоков - просто висла и все. Причом висли именно агенты и висело до тех пор пока руками не прибъешь процесс через таскменеджер .... Отключил часть ядер, пошел просчет. Думаю разработчики должны что то сделать чтобы проблема была явной. Если уж оптимизатору нужно именно надцать гигов памяти на просчет - это надо явно написать чем то типа алерта. Хотя еще раз напомню про своп. У меня установлен Xmeters ... так что загрузку памяти я вижу визуально прямо на панели задач.
Думаю есть еще какой то глюк связанный именно с CPU АМД и раньше такого не было - хотя советник был тот же. Симптомы такие - задействовано всего 5 ядер .... и просчет висит... и это точно не память, так как тот же советник считал при загрузке 16 потоками без проблем, и эта проблема какая то плавающая, то она есть то ее нет. Если запустить тест не в оптимизаторе - он нормально исполняется. Не раз замечал такое. Вообщем надо разбираться.
По поводу тормозов на сетевых агентах - воз и ныне там. "Одно ядро - одно задание" - недоступно для понимания разработчиков. Как и раньше 10 ядрам раздаст по 30 заданий, и еще 30 сетевых агентов простаивают. Долго раздает задания о чом то думая. Вообщем тут тормоза сплошные.
и да забыл: Всем огромное спасибо за участие, посильную помощь и советы.to Renat Fatkhullin
Все таки я хочу тему еще раз поднять и задать вопрос конкретно Renat Fatkhullin
1. Я выполняю оптимизацию на локальной ферме из нескольких совершенно разных по производительности серверах и увидел ну просто страшные задержки при оптимизации вызванные именно тем что CPU имеют разную производительность. Предположим есть сервера с CPU Xeon E5-2620 v2 (2.1 Ггц), Xeon E5-2620 0 (2,00 Ггц), i7-3820 (3.6 Ггц), Xeon E3-1245 (3,7 Ггц), Ryzen 7 2700 , Ryzen 9 3900X, Ryzen 9 3950X. Текущий алгоритм работает так: формирует пачку заданий, делит эту пачку заданий поровну на каждое доступное ядро. Теперь учитывая то что имеем тихоходные CPU Xeon E5-2620 0 (2,00 Ггц) и Xeon E5-2620 v2 (2.1 Ггц) получается что ферма посчитала свои задания и простаивает, а эти два CPU не просчитали и половины заданий. Таким образом вся ферма тупо стоит. Так происходит и будет происходить потому что CPU имеют разную скорость и до тех пор пока задания раздаются пакетами. Опыт показывает что сетевые задержки вообще не имеют значения и они ничтожны. Можно ли уже переделать алгоритм раздачи заданий: раздавать не несколько заданий каждому доступному ядру а "давать каждому освободившемуся ядру - одно задание из текущей пачки генерации"?
2. Можно ли добавить сохранение результатов тестирования в xml файл каждые 10 минут ....и запуск с места последнего сохранения?
Мы занялись полным переписыванием тестера и оптимизатора.
Будем кардинально переделывать и исправлять накопленные проблемы.
Мы занялись полным переписыванием тестера и оптимизатора.
Будем кардинально переделывать и исправлять накопленные проблемы.
Будет ли:
1. Более быстрая реакция на отвал агента, когда допустим, при отсутствии отзыва от агента выдача пакетов прерывается на минуты и пакеты перераспределяются.
2. Будит ли реализована возможность закачки в одном экземпляре данных для всех агентов на удаленной машине?
3. Будет ли решена проблема передачи больших объемов данных, когда с агентом рвется соединение недокачав все нужные для оптимизации данные (файлы)?
Меня вот еще один момент беспокоит ....
допустим идет оптимизация и в этот момент происходит обновление метатрейдера агента .... при этом агент ведь имел задание (точнее пакет заданий), оно будет потеряно или будет пересчитано?