ruby-on-rails - Rails 和 phusion 乘客中的内存泄漏问题

Question

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

令人难以置信的是，在重新启动操作系统一小时后，一个机架进程如何使用 885.9 MB 的私有(private)脏 RSS 内存，而总使用量降至 100 mb。现在一小时后它是 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”来杀死一个消耗这么多内存的机架进程，那会有帮助吗？

Answer 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)

你展示的那个进程看起来像一个普通的 worker ，试着在受控条件下杀死有问题的进程，看看会发生什么，可能没什么坏处。

看看您是否可以将这种情况与某个(通常是长时间运行的) Controller 操作或 apache 重新启动/重新加载(定期出现此问题，20 个进程中有 1 个在重新启动后变得疯狂)联系起来。

扩展 rails 日志，使其包含 PID(例如 https://gist.github.com/krutten/1091611)并制作一个简单的脚本，每分钟左右将内存使用转储到一个文件中(确保你没有填满磁盘)——这将使你能够准确地知道什么时候一个进程开始膨胀，然后在日志中跟踪它之前/之后所做的事情