Бешенный кеш агентов тестирования
Всем доброго времени суток!
Столкнулся с такой проблемой:
Имея 32 логических процессора в системе - использую для оптимизации 32 агента соответственно (+ еще 40 удаленных)
Каждый агент довольно быстро наращивает кеш совершенно неадекватных размеров 2-2,6ГБ что в общей сложности составило более 70ГБ за день! Кеш сам не удаляется, и постоянно растет. Остановило это безумие только кончившееся место на диске. После чего агенты тупо перестают работать.
Собственно вопросы следующие:
Сталкивался ли кто-то с такой проблемой? Как с этим бороться? Из-за чего может возникать такие объемы кеша?
Написал запрос в сервисдеск, пока тишина.
Объём кэша зависит от количества сгенерированных тиков (т.е., чем больше период теста и количество символов, тем больше кэш).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
Место под кэш освобождается через 5 минут простоя агента.
Дополнительно место может занимать история тиков для агентов тестера, если агенты используются в облаке (история тиков со временем тоже чистится, но счёт идет на дни или недели)
Кстати, облачные агенты и локальные - это разные агенты. На картинке облачные агенты на этом же компьютере добавлены в локальную сетевую ферму - Voilà! Получилось 8 агентов тестирования на процессоре с двумя ядрами и четырьмя логическими процессорами (стоит ли так делать - другой вопрос).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
Тестер вообще не имеет каких либо настроек, в следствии чего невозможно оптимизировать его работу под свою систему. На выходе мы получаем насилование жесткого диска бешеным числом перезаписи мелких файлов (максимально заметил до 800Гб/день на SSD 120ГБ при 32х агентах в системе), и самое забавное что ядра в этот момент простаивают.
Частично решил проблему запуском 4х разных тестеров в портативном режиме на разных физических дисках. В т.ч. и RAM-diske, т.к. тестер оставляет без внимания большой объем памяти.
Кстати работа агента с кешем на рам-диске, зачастую увеличивает производительность до 3х раз! Что еще раз указывает на отвратительную организацию работы тестера.
Кстати, облачные агенты и локальные - это разные агенты. На картинке облачные агенты на этом же компьютере добавлены в локальную сетевую ферму - Voilà! Получилось 8 агентов тестирования на процессоре с двумя ядрами и четырьмя логическими процессорами (стоит ли так делать - другой вопрос).
В этом и заключается (да простят меня разработчики) тупость организации тестера, когда число агентов из преимущества превращается в проблему.
Тестер вообще не имеет каких либо настроек, в следствии чего невозможно оптимизировать его работу под свою систему. На выходе мы получаем насилование жесткого диска бешеным числом перезаписи мелких файлов (максимально заметил до 800Гб/день на SSD 120ГБ при 32х агентах в системе), и самое забавное что ядра в этот момент простаивают.
...
Кстати работа агента с кешем на рам-диске, зачастую увеличивает производительность до 3х раз! Что еще раз указывает на отвратительную организацию работы тестера.
...
Необходимость считать несколько гигабайтов данных с диска - это "отвратительная организация"? Даже просто считать 1 гб данных с ssd на средней скорости в 200мб в сек займет 5 секунд. А если там 4-32 агента?
Вы просто задумайтесь о технической стороне задачи. Ничего бесплатного нет и никто технические требования на ноль не перемножает.
Техническое решение и уровень оптимизации агентов изумительные - мы вложили в это дикое количество труда и выцарапывали миллисекунды из всех процессов. Не забывайте об объемах данных, ставьте больше оперативки, ставьте большие ssd, ставьте рам диски и все будет ускорено.
Цены на все это уже приемлемые, а класс и обьем решаемых требуют серьезного подхода.
Каждый агент довольно быстро наращивает кеш совершенно неадекватных размеров 2-2,6ГБ что в общей сложности составило более 70ГБ за день! Кеш сам не удаляется, и постоянно растет. Остановило это безумие только кончившееся место на диске. После чего агенты тупо перестают работать.
Что там кешировать возможно в таких объемах?!
С кешами данных у нас все в порядке. И на диске держим, и в памяти храним в ожидании повторных запусков. Обратите внимание, насколько быстрее проходит повторный расчет на том же агенте(один агент и один проход возьмите для демонстрации эффекта).
И еще - с дисками мы работаем очень щадяще. Пишем большими кратными кусками и явно понимаем особенности ssd дисков.
Обычно трейдеры предпочитают смотреть размер папки, не замечая, что там десяток гигабайтов лично ими сгенерированных обширных логов.
Частично решил проблему запуском 4х разных тестеров в портативном режиме на разных физических дисках. В т.ч. и RAM-diske, т.к. тестер оставляет без внимания большой объем памяти.
Кстати работа агента с кешем на рам-диске, зачастую увеличивает производительность до 3х раз! Что еще раз указывает на отвратительную организацию работы тестера.
По какой причине организация RAM-диска увеличивает в разы производительность, если уровень оптимизации агентов "изумительный"? По-моему, логичные вопросы, хоть и неприятные.
ЗЫ Нужна какая-нибудь прога, которая бы терла логи агентов. Ни к чему они в таких количествах. Да и Print+Alert должны самим юзером в коде отключаться во время оптимизаций.
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
А вы посмотрите у себя сами вместо оперирования форумными заявлениями.
По какой причине организация RAM-диска увеличивает в разы производительность, если уровень оптимизации агентов "изумительный"? По-моему, логичные вопросы, хоть и неприятные.
Потому что мы не имеем права съесть 100% оперативки под кеш и держать его бесконечно долго. А вот если человек сам создал рам диск под 32-64 гб, перенес туда агентов и стал активно работать с диском, то да - можно получить ускорение дисковых операций в разы.
Но именно дисковых операций, а не "сразу во всем в N раз".
Что тестер работает с данными изумительно, видно каждому, кто его использует в постоянном режиме и получает массу преимуществ от разогретых кешей тестера, ожидающего новых прогонов в фоновом режиме. Обычно эксперименты - это десятки и сотни запусков тестера с постоянной перекомпиляцией кода.
ЗЫ Нужна какая-нибудь прога, которая бы терла логи агентов. Ни к чему они в таких количествах. Да и Print+Alert должны самим юзером в коде отключаться во время оптимизаций.
Логи тестера стираются автоматически. Кто использует тестер, тот это знает. И кеши тестера подтираются самим терминалом, как только он понимает, что тестером уже не пользуются.
Топикстартер затеял тему в режиме "доколе?" и сделал несколько бездоказательных заявлений. Если бы он предоставил правильно собранные данные, то 50% вопросов отпало бы на этапе сбора данных.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Всем доброго времени суток!
Столкнулся с такой проблемой:
Имея 32 логических процессора в системе - использую для оптимизации 32 агента соответственно (+ еще 40 удаленных)
Каждый агент довольно быстро наращивает кеш совершенно неадекватных размеров 2-2,6ГБ что в общей сложности составило более 70ГБ за день! Кеш сам не удаляется, и постоянно растет. Остановило это безумие только кончившееся место на диске. После чего агенты тупо перестают работать.
Собственно вопросы следующие:
Сталкивался ли кто-то с такой проблемой? Как с этим бороться? Из-за чего может возникать такие объемы кеша?
Написал запрос в сервисдеск, пока тишина.