【问题标题】:memory leak issue in rails and phusion passengerRails 和 phusion 乘客中的内存泄漏问题
【发布时间】:2013-12-04 20:06:47
【问题描述】:

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 的私有脏 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”来杀死一个消耗这么多内存的机架进程,会有帮助吗?

【问题讨论】:

  • 我在运行 top 命令时也注意到了这种疯狂:1906 guarddog 20 0 1174m 940m 4180 R 99.9 15.8 365:40.91 ruby​​。 99% 的 CPU 使用率!

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


【解决方案1】:
  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)并制作一个简单的脚本,每分钟左右将内存使用转储到一个文件中(确保您没有填满磁盘) - 这将使您能够确切知道进程何时开始膨胀,然后在日志中跟踪它在发生这种情况之前/之后所做的事情

【讨论】:

  • 感谢您的回复,当您说“尝试在受控条件下杀死有问题的进程”时,您的意思是“kill -9 1906”之类的吗?
  • Np :) 是的,但是先尝试正常的 kill(只是 kill 1906),看看它是否决定和平地离开(在这种情况下,它可能只是应用程序膨胀)。如果失败,请尝试 kill -9,并在执行此操作时监控应用程序 - 如果在那之后有任何问题,只需重新启动 apache 服务器并查看是否有任何旧进程仍然存在
  • 我正在查看您链接到的一篇文章,其中引用了这一点:“我们经常建议人们尝试 Rack::Bug、MemoryLogic 或 Oink”。这 3 个中的任何一个都适用于 rails 3 应用程序吗?
  • Afaik,它们都很合适,但它们的用例不同,其中一些警告在使用跟踪等时会影响性能,所以如果你想使用它们,最好阅读文档和看看哪一个最适合您的情况
猜你喜欢
  • 2010-11-23
  • 2011-01-07
  • 1970-01-01
  • 2011-03-29
  • 1970-01-01
  • 2012-12-19
  • 1970-01-01
  • 2016-07-28
相关资源
最近更新 更多