Найти утечки памяти в приложении Rails - PullRequest
Новая
       9

Найти утечки памяти в приложении Rails

4 голосов
/ 15 сентября 2011

У меня есть веб-приложение на Ruby on Rails.Для запуска приложения мы используем кластеры mongrel, запущенные на apcahe httpd.Мы столкнулись с проблемой огромного потребления памяти в приложении.(RedHat, Ruby 1.8.7, Rails 2.3.5, RAM 8GB)

Дело в том, что после запуска веб-сервера (запуска кластеров mongrel) использование памяти, похоже, увеличивается.Например, если свободная память (ОЗУ) при запуске веб-сервера составляла 6 ГБ.Через 2 дня объем свободной памяти становится 3 ГБ, даже если на сайте нет трафика.Если веб-сервер не перезагружается в течение недели, кажется, что память увеличивается и использует 8 ГБ ОЗУ и вызывает проблемы «нет памяти для выделения» для таких процессов, как генерация PDF с использованием «PrinceXML», отправка почты с использованием Sendmail (я думаю, что этообъем памяти ).При перезапуске веб-сервера свободная память возвращается к 6 ГБ.

Это случай утечки памяти в приложении Rails?Как проверить приложение на утечки памяти?Я нашел инструмент для проверки утечек памяти bleak_house , но когда я устанавливаю его как драгоценный камень, как показано в этой ссылке , он дает No command bleak found, когда я запускаю 'bleak / tmp /bleak.5979.000.dump 'для анализа.

Я использую PrinceXML для генерации отчетов в формате PDF и sendmail для отправки почты.На этом сервере также запущен экземпляр Jasper Server. Любой, пожалуйста, помогите .

Вот результат команды top во время перегрузки памяти. 

-bash-3.2$ top

top - 10:34:10 up 14 days,  7:40,  2 users,  load average: 0.24, 0.40, 0.39
Tasks: 181 total,   1 running, 177 sleeping,   2 stopped,   1 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8173984k total,  8011564k used,   162420k free,    10044k buffers
Swap:  2096472k total,   152624k used,  1943848k free,  2012016k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
  858 **nt*rsc  15   0 12748 1168  832 R 173.5  0.0   0:00.36 top               
    1 root      15   0 10356  108   76 S  0.0  0.0   0:17.10 init               
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.10 migration/0        
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0        
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0         
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.12 migration/1        
    6 root      34  19     0    0    0 S  0.0  0.0   0:00.12 ksoftirqd/1        
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1         
    8 root      RT  -5     0    0    0 S  0.0  0.0   0:00.70 migration/2        
    9 root      34  19     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/2        
   10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/2         
   11 root      RT  -5     0    0    0 S  0.0  0.0   0:00.67 migration/3        
   12 root      34  19     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/3        
   13 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/3         
   14 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/0           
   15 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/1           
   16 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/2

1 Ответ

3 голосов
/ 15 сентября 2011

Я бы попробовал использовать passenger (который автоматически перезапускает и управляет экземплярами рельсов, которые становятся слишком большими в памяти - намного проще, чем перезагрузка шавок, которые отклонились от нормальных ограничений памяти). Также вам может повезти с ruby ​​Enterprise Edition с версией 1.8.7, которая переносит некоторые исправления управления памятью из 1.9 (например, позволяет виртуальной машине сокращаться, когда она использует меньше памяти) - это изменение могло бы сработать, вернувшись к нормальной версии 1.8.7 хотя я не уверен. Преимущество REE заключается в том, что вы можете уменьшить потребление памяти на 33% для рельсовых приложений.

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

http://www.modrails.com/

Он также имеет хорошие аналитические функции памяти

http://www.modrails.com/documentation/Users%20guide%20Apache.html#_analysis_and_system_maintenance

...