Безумная кложурная жесть

[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 занимаются.

Comments

[kiryl.livejournal.com]

Похоже на lock contention. Интересно на каком уровне: жаба или глубже в ОС. Это винда или как?

С локами есть куча тонких эффекторов. Коллеги недавно статейку опубликовали по поводу некоторых из них: www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf

[metaclass.livejournal.com]

У меня там локов конкретно во время расчета нет - все взаимодействия между потоками производятся по завершению расчетов. И я на 99% уверен, что во внутренностях clojure нету неявных блокировок - это бы полностью противоречило всей идеологии языка.

Сейчас я повторил эксперимент, постепенно наращивая количество запросов - теперь нормально, 4 минуты на 64 отчета. Но были мелкие изменения в условиях эксперимента, надо бы воспроизвести в оригинальных условиях.

Вообще говоря, там очень много разных эффектов - например, первая версия тупила на том, что в пуле коннектов к БД было ограничение на 8 активных коннектов.

[kiryl.livejournal.com]

Локи в любом случае есть. Хотя бы в memory management в ядре.

[tonsky.livejournal.com]

В stm есть, Рич сам говорил: не фантазируйте, конечно, локи есть. Главное, что наружу не торчат.

[prepor.livejournal.com]

Во всем, что касается shared мемори (stm, атомы, агенты) кложа, конечно, полна локов. Локи вредны не как таковые, а как интерфейс.