rails和phusion乘客的内存泄漏问题

时间:2013-12-04 20:06:48

标签: ruby-on-rails memory-leaks passenger

rails网站运行速度很慢,我不得不重新启动操作系统,但是在重新启动ubuntu后仅1小时,系统再次出现了令人难以置信的缓慢,所以我检查了乘客内存统计信息:

------ Passenger processes ------
PID    VMSize     Private   Name
---------------------------------
1076   215.8 MB   0.3 MB    PassengerWatchdog
1085   2022.3 MB  4.4 MB    PassengerHelperAgent
1089   109.4 MB   6.4 MB    Passenger spawn server
1093   159.2 MB   0.8 MB    PassengerLoggingAgent
1883   398.1 MB   110.1 MB  Rack: /home/guarddog/public_html/guarddog.com/current
1906   1174.6 MB  885.9 MB  Rack: /home/guarddog/public_html/guarddog.com/current
3648   370.1 MB   131.9 MB  Rack: /home/guarddog/public_html/guarddog.com/current
14830  370.6 MB   83.0 MB   Rack: /home/guarddog/public_html/guarddog.com/current
15124  401.2 MB   113.9 MB  Rack: /home/guarddog/public_html/guarddog.com/current
15239  413.5 MB   127.7 MB  Rack: /home/guarddog/public_html/guarddog.com/current
15277  400.5 MB   113.6 MB  Rack: /home/guarddog/public_html/guarddog.com/current
15285  357.1 MB   70.1 MB   Rack: /home/guarddog/public_html/guarddog.com/current
### Processes: 12
### Total private dirty RSS: 1648.10 MB

令人难以置信的是,当使用率降低到100 MB时,一个机架进程在重新启动操作系统一小时后使用了885.9 MB的私有脏RSS内存。现在一小时后,它的速度为1648.10 mb。网站速度太慢,页面甚至无法加载。

我认为这是一个内存泄漏所以我在整个应用程序中添加了这行代码:

puts "Object count: #{ObjectSpace.count_objects}"  

但我不知道如何解释它给我的数据:

Object count: {:TOTAL=>2379635, :FREE=>318247, :T_OBJECT=>35074, :T_CLASS=>6707, :T_MODULE=>1760, :T_FLOAT=>174, :T_STRING=>1777046, :T_REGEXP=>2821, :T_ARRAY=>75160, :T_HASH=>64227, :T_STRUCT=>774, :T_BIGNUM=>7, :T_FILE=>7, :T_DATA=>55075, :T_MATCH=>10, :T_COMPLEX=>1, :T_RATIONAL=>63, :T_NODE=>37652, :T_ICLASS=>4830}

注意我只在本地计算机上运行ObjectSpace.count_objects,因为我的ubuntu服务器速度太慢,甚至无法加载页面。

以下是其他一些操作系统统计信息:

$ cat /proc/meminfo                                                        
MemTotal:        6113156 kB
MemFree:         3027204 kB
Buffers:          103540 kB
Cached:           261544 kB
SwapCached:            0 kB
Active:          2641168 kB
Inactive:         248316 kB
Active(anon):    2524652 kB
Inactive(anon):      328 kB
Active(file):     116516 kB
Inactive(file):   247988 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       6287356 kB
SwapFree:        6287356 kB
Dirty:                36 kB
Writeback:             0 kB
AnonPages:       2524444 kB
Mapped:            30108 kB
Shmem:               568 kB
Slab:              77268 kB
SReclaimable:      48528 kB
SUnreclaim:        28740 kB
KernelStack:        4648 kB
PageTables:        43044 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     9343932 kB
Committed_AS:    5179468 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      293056 kB
VmallocChunk:   34359442172 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       46848 kB
DirectMap2M:     5195776 kB

df
Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/roadrunner-root 134821120 22277596 105695012  18% /
udev                          3047064        4   3047060   1% /dev
tmpfs                         1222632      252   1222380   1% /run
none                             5120        0      5120   0% /run/lock
none                          3056576       88   3056488   1% /run/shm
none                           102400        0    102400   0% /run/user
/dev/sda1                      233191    29079    191671  14% /boot

另一方面,如果我运行“kill -9 1906”来杀死那个占用大量内存的机架进程,那会有帮助吗?

1 个答案:

答案 0 :(得分:3)

  1. 首先,热修复眼前的生产问题,实施看门狗 - http://dev.mensfeld.pl/2012/08/simple-rubyrails-passenger-memory-consumption-limit-monitoring/,然后寻找泄漏或膨胀(https://blog.engineyard.com/2009/thats-not-a-memory-leak-its-bloat
  2. 您展示的过程看起来就像普通员工一样,尝试在受控条件下查杀违规流程,看看会发生什么,可能没什么不好。
  3. 看看你是否可以将这种情况与某个(通常是长时间运行的)控制器操作相关联,或者apache重新启动/重新加载(定期出现此问题,重启后,20个进程中的1个进入疯狂状态。)
  4. 扩展rails日志,使它们包含PID(例如https://gist.github.com/krutten/1091611)并制作一个简单的脚本,每隔一分钟就将内存使用转储到一个文件中(确保你没有填满你的磁盘) - 这将启用你要确切知道一个进程何时开始膨胀,然后在日志中追踪它之前/正在发生的事情