Я использую Sidekiq 4.1.2 в качестве фонового процессора обработки на Heroku (с Heroku Redis 3.2.0).Ошибка утечки Sidekiq на Heroku
Проблема в том, что процесс Sidekiq потребляет больше памяти с каждой минутой и никогда не опускается. Иногда требуется всего 10 минут, чтобы расти с 300Mb до 2Gb (тогда он умирает, ужасно). Конечно, моя первая мысль была «О, похоже, я испортил управление памятью фоновой работы!».
Природа моих фоновых заданий состоит в том, что они занимают много времени, и они создают много объектов, которые сохраняются в БД и не используются снова. Поэтому я добавил периодические вызовы сборщика мусора вручную: GC.start после каждого 1000 обработанных объектов.
Я тестировал его на своей локальной машине и был освобожден: процесс Sidekiq с 10 потоками оставался ниже 500 МБ. Затем я развернул этот код на Heroku, но, увы, ненасытный голод Sidekiq для памяти все еще был на месте: потребление памяти только увеличивается и никогда не уменьшается, несмотря на периодические ручные пуски сборщика мусора.
Поэтому проблема следующая: тот же код не просачивается на мою машину, но протекает на Heroku. Что может вызвать такое поведение? Что я должен сделать, чтобы точно определить это?
Вы уверены, что код является потокобезопасным? Может стоить взглянуть на https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting – DMH
Вы используете Ruby 2.1 на Heroku? –
У меня была аналогичная проблема на днях, которая заставила меня подумать, что это был sidekiq, но в конечном итоге мои активы были загружены в порядке, который привел к массовой утечке. Я бы сказал, что если он работает на вашем локальном компьютере, то есть что-то в вашей конфигурации производства. это как-то приводит к этой проблеме. Для меня это было то, что активы были предварительно скомпилированы, и, таким образом, заказ был изменен. Для вас это будет нечто другое, но приближение к нему из этого мышления может вам помочь. – bkunzi01