zed.0xff.me

поиск утечек памяти в ruby/rails

0. Введение

Для начала – что такое классические утечки памяти? Это когда мы (или не мы) сделали malloc(), но забыли сделать free(). Но на деле эта память уже не используется и должна бы быть давно уже возвращена системе через free().

Что такое утечки памяти в ruby? Это висящие в памяти объекты(А), на которые есть ссылки с каких-то глобальных объектов(Б), но фактически (А) уже никому не нужны, а с них, в свою очередь еще есть кучи и кучи ссылок на другие объекты, которые занимают туеву хучу памяти, и не могут быть освобождены сборщиком мусора, потому что на них есть ссылки с других объектов.

Сложно? Сейчас будет еще сложнее :) Плюс к упомянутым выше специфичным для ruby утечкам памяти из-за ссылок на объекты, в ruby также могут быть (и есть!) и классические утечки памяти. В основном в различных экстеншнах, обычно подключаемых через gem’ы. Но и в самом интерпретаторе ruby вероятно где-то еще остались необнаруженные утечки.. только и количество и вероятность их обнаружения на пару-тройку порядков ниже, чем в сторонних gem’ах. Потому что в разработке ruby явно участвует больше и людей и тестеров, чем в разработке любого gem’а.

1. Как узнать что память течет?

Банально :) Смотрим периодически на наш ruby-процесс через ps или top, и если размер памяти процесса постоянно увеличивается, и вскоре начинает занимать всю физическую память + своп – то серьезные утечки памяти скорее всего есть.
Но это способ эмпирический, а вот более практический – нужно ограничить процессу память каким-нибудь значительным объемом (например 512Мб)

1

  Process.setrlimit Process::RLIMIT_AS, 512*1024*1024, 512*1024*1024

и погонять процесс. Если он через какое-то время (минуты, часы, дни, месяцы, … :) выпадает с криком [FATAL] failed to allocate memory – значит утечки есть.
Этот способ не сработает, или сработает неправильно, если работа процесса связана с обработкой больших объемов данных (сопоставимых с 512Мб в данном случае).

2. Как бороться?

Для того чтобы бороться надо сначала узнать с кем конкретно бороться :) А мы пока узнали только тот факт что память течет. Далее нужно определить виновника. Для этого есть как минимум три ортогональных способа:

  1. valgrind – для поиска утечек в самом ruby и экстеншнах. для нормальной работы требует специально-фигурно-выпиленный бинарник ruby. патчи тут. К текущей версии ruby (ruby-1.8.7-p249) подходят с трудом.
  2. bleak_house – инструмент для отслеживания аллокейшнов ruby-объектов. Подходит для Rails.
  3. метод эмпирической дихотомии – универсальный способ :) – во-первых, надо определить что память течет (п.1), во-вторых, берем большой топор и начинаем вырезать или комментировать куски кода.. после каждой ампутации заново проверям осталась ли утечка. если осталась – продолжаем ампутацию, если исчезла – смотрим внутрь отрезанного куска, вплоть до локализации “текущего” метода экстеншна либо присвоения глобальной переменной ($global_var) или переменной класса (@@class_var).

P.S. Все утечки актуальны только во время исполнения приложения. Как только приложение завершается, вся память всегда возвращается системе.