?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

144 мгц
metaclass
Чо-то сплошная морзянка на 144 мгц (144.060, 144.300 итд). То ли радиолюбители в выходные дорвались до хобби, то ли прохождение хорошее.

Как отличить змагара от замаскированного агента рэжыма
metaclass
Если змагар пишет как псих, паленые лекарства которого украли аннунаки (см. бай-политикс) - это настоящий змагар.
Если же змагар пишет связно и пользуется логикой - это поддельный змагар, он или хочет пилить гранты или агент кровавого режима.

Безумная кложурная жесть
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 занимаются.