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

[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

[andrew kondratovich (from livejournal.com)]

есть такое.

с агентами проще - можно выбирать куда совать.

можно поменять экзекутор - но он затронет весь рантайм.

[metaclass.livejournal.com]

Да я тут в процессе насмотрелся на java.util.concurrent - там все сделано крайне грамотно, можно использовать напрямую, создать отдельный пул и в нем считать.

[tonsky.livejournal.com]

мы так и делаем: scheduledthreadpool, timer, очереди

[tonsky.livejournal.com]

почему весь? send-via же

[andrew kondratovich (from livejournal.com)]

Ага... в итоге экзекутор для фьючеров ставим глобальный, а для агентов - экплисит. не кошерно как-то.