![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Безумная кложурная жесть
Делаю генератор отчетов, у которого часть работы - запросы к БД и часть - постобработка. Все это работает в фоновых потоках clojure (внутри future) и паралелльно еще несколько потоков (из ScheduledThreadPool и его вариаций из java.util.concurrent) выполняют всякую вспомогательную работу типа "очистить старые данные", "пересчитать изменения пришедшие в очередь в БД".
future в clojure реализованы в том же thread pool что и функция send-off для агентов. Этот thread pool не имеет ограничений по размеру и изначально предполагался для операций, ожидающих i/o, а не cpu-bound. Пока отчет считается в БД - это нормально, но когда начинается постобработка, при превышении некоторого порога количества потоков - возникают совершенно непропорциональные тормоза, типа 30 отчетов одновременно считается за 2 минуты, 64 отчета считаются 30 минут.
Надо как-то более равномерно распределить работу по времени, чтобы количество нагружающих CPU потоков было ограничено, что ли. И вообще, надо как-то осилить профилирование нагрузки, чтобы знать, чем там кложурь и JVM занимаются.
future в clojure реализованы в том же thread pool что и функция send-off для агентов. Этот thread pool не имеет ограничений по размеру и изначально предполагался для операций, ожидающих i/o, а не cpu-bound. Пока отчет считается в БД - это нормально, но когда начинается постобработка, при превышении некоторого порога количества потоков - возникают совершенно непропорциональные тормоза, типа 30 отчетов одновременно считается за 2 минуты, 64 отчета считаются 30 минут.
Надо как-то более равномерно распределить работу по времени, чтобы количество нагружающих CPU потоков было ограничено, что ли. И вообще, надо как-то осилить профилирование нагрузки, чтобы знать, чем там кложурь и JVM занимаются.
no subject
С локами есть куча тонких эффекторов. Коллеги недавно статейку опубликовали по поводу некоторых из них: www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf
no subject
Сейчас я повторил эксперимент, постепенно наращивая количество запросов - теперь нормально, 4 минуты на 64 отчета. Но были мелкие изменения в условиях эксперимента, надо бы воспроизвести в оригинальных условиях.
Вообще говоря, там очень много разных эффектов - например, первая версия тупила на том, что в пуле коннектов к БД было ограничение на 8 активных коннектов.
no subject
no subject
no subject
no subject
Вот где жестокий реальный мир наносит ответный удар. Чё-то ещё...да есть книжки, которые советовали ребята из Oracle, по перформансу, но может там все не так страшно.
no subject
no subject
no subject
Я правда сомневаюсь, что где-нибудь, кроме русскоязычного интернета, жизнеспособна идея "дрочить на карму" :)
no subject
no subject
no subject
no subject
no subject
no subject
Оттуда большинство переводимых статей хабровских.
no subject
с агентами проще - можно выбирать куда совать.
можно поменять экзекутор - но он затронет весь рантайм.
no subject
no subject
no subject
no subject
no subject
no subject