Огромная утечка памяти / раздувание после обновления с Rails 3.0 до Rails 3.2 (Ruby 1.9.3 + Passenger)

Question

На прошлой неделе мы обновили небольшой проект, который работал на Rails 3.0.1, до Rails 3.2.2.

Вскоре после обновления мы узнали, что иногда 2-3 раза в день мы наблюдаем огромный процесс Phusion Passenger (1-5 ГБ).

Мы работаем с Phusion Passenger 3.0.11 и Ruby 1.9.3-p0. Мы уже пробовали разные версии Ruby (1.9.2-p290 и 1.9.3-p125) без успеха.

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

Когда мы вернулись к Rails 3.0.1, проблема исчезла. У кого-нибудь есть подобные проблемы? Мы действительно проверили наш код на возможные утечки памяти, такие как слишком много экземпляров ActiveRecord, но не нашли ни одного.

Думаешь, стоит попробовать Единорога вместо Пассажира? Или, скорее всего, мы столкнемся с той же проблемой?

Любые предложения о том, как отследить утечку памяти, приветствуются. Мы уже настроили newrelic, но он не показывает подробную информацию об утечке памяти.

Answer 1

Если это Linux, совместимый с Red Hat, вы можете использовать SystemTap.Я не уверен, доступен ли SystemTap в системах Debian / Ubuntu, если нет, то есть альтернатива DTrace.Вот несколько статей - я довольно успешно выследил несколько регрессий, хотя ни одна из них не была проблемой с памятью (возможно, вы можете найти сценарий STP, который мог бы помочь вам).Читайте здесь:

http://lukas.zapletalovi.com/2012/02/peek-into-your-ruby-app-with-systemtap.html http://lukas.zapletalovi.com/2012/01/probing-ruby-apps-with-systemtap-in.html http://sourceware.org/systemtap/wiki/RubyMarker

Последняя ссылка показывает пробники, которые вы можете использовать в SystemTaps в Ruby.Есть мысли, как gc run или распределение памяти, может помочь вам.Удачи!

Answer 2

Мне было бы интересно узнать, что показывает статистика памяти пассажира и какой тип памяти у вас установлен для пассажира для PassengerMaxPoolSize PassengerPoolIdleTime и для любых других настроек пассажира.

Как вы обновили пассажира?

Какая у вас настройка apache? Префорк или рабочий?

Я подозреваю, что вы видите плохую производительность gc, попытайтесь настроить их, поместив это в обертку вокруг рубина, который использует пассажир:

#!/bin/sh
export RUBY_HEAP_MIN_SLOTS=600000
export RUBY_GC_MALLOC_LIMIT=59000000
export RUBY_FREE_MIN=200000
exec "/usr/bin/ruby" "$@"

Это должно исправить некоторые проблемы с производительностью, которые вы видите в целом из-за плохих значений по умолчанию ruby ​​gc.