Безумная кложурная жесть
May. 5th, 2013 10:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassДелаю генератор отчетов, у которого часть работы - запросы к БД и часть - постобработка. Все это работает в фоновых потоках 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 занимаются.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-05-05 08:02 pm (UTC)С локами есть куча тонких эффекторов. Коллеги недавно статейку опубликовали по поводу некоторых из них: www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf
no subject
Date: 2013-05-05 08:13 pm (UTC)Сейчас я повторил эксперимент, постепенно наращивая количество запросов - теперь нормально, 4 минуты на 64 отчета. Но были мелкие изменения в условиях эксперимента, надо бы воспроизвести в оригинальных условиях.
Вообще говоря, там очень много разных эффектов - например, первая версия тупила на том, что в пуле коннектов к БД было ограничение на 8 активных коннектов.
no subject
Date: 2013-05-05 09:03 pm (UTC)no subject
Date: 2013-05-06 10:29 am (UTC)no subject
Date: 2013-05-06 02:13 pm (UTC)no subject
Date: 2013-05-05 08:08 pm (UTC)Вот где жестокий реальный мир наносит ответный удар. Чё-то ещё...да есть книжки, которые советовали ребята из Oracle, по перформансу, но может там все не так страшно.
no subject
Date: 2013-05-05 08:16 pm (UTC)no subject
Date: 2013-05-05 08:24 pm (UTC)no subject
Date: 2013-05-05 08:27 pm (UTC)Я правда сомневаюсь, что где-нибудь, кроме русскоязычного интернета, жизнеспособна идея "дрочить на карму" :)
no subject
Date: 2013-05-05 08:49 pm (UTC)no subject
Date: 2013-05-06 04:00 am (UTC)no subject
Date: 2013-05-06 02:23 pm (UTC)no subject
Date: 2013-05-05 09:24 pm (UTC)no subject
Date: 2013-05-05 10:20 pm (UTC)no subject
Date: 2013-05-06 04:21 am (UTC)Оттуда большинство переводимых статей хабровских.
no subject
Date: 2013-05-05 08:11 pm (UTC)с агентами проще - можно выбирать куда совать.
можно поменять экзекутор - но он затронет весь рантайм.
no subject
Date: 2013-05-05 08:15 pm (UTC)no subject
Date: 2013-05-06 10:31 am (UTC)no subject
Date: 2013-05-06 10:37 am (UTC)no subject
Date: 2013-05-06 01:17 pm (UTC)no subject
Date: 2013-05-06 07:27 am (UTC)no subject
Date: 2013-05-06 03:43 pm (UTC)