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

[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

[andymur.livejournal.com]

VisualVM в помощь, на хабре статья (http://habrahabr.ru/post/61857/) хорошая.

Вот где жестокий реальный мир наносит ответный удар. Чё-то ещё...да есть книжки, которые советовали ребята из Oracle, по перформансу, но может там все не так страшно.

[andrew kondratovich (from livejournal.com)]

есть такое.

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

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

[bydlorus.livejournal.com]

Когда я читаю про генераторы отчётов на closure, то в ужасе просыпаюсь, а рука в горшке.