加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

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

发布时间:2020-12-16 21:01:20 所属栏目:百科 来源:网络整理
导读:rails网站运行速度很慢,我不得不重新启动操作系统,但是在重新启动ubuntu后仅1小时,系统再次出现了令人难以置信的缓慢,所以我检查了乘客内存统计信息: ------ Passenger processes ------PID VMSize Private Name---------------------------------1076 215.
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”来杀死那个占用大量内存的机架进程,那会有帮助吗?

解决方法

>首先,热修复眼前的生产问题,实施看门狗 – 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)
>你展示的那个过程看起来像一个普通的工人,尝试在受控条件下杀死违规过程,看看会发生什么,可能没什么不好.
>看看你是否可以将这种情况与某个(通常是长时间运行的)控制器操作相关联,或者apache重新启动/重新加载(定期出现此问题,20个进程中的1个在重新启动后进入疯狂状态).
>扩展rails日志,使它们包含PID(例如 https://gist.github.com/krutten/1091611)并制作一个简单的脚本,每分钟左右将内存使用转储到一个文件中(确保你没有填满你的磁盘) – 这将使你能够准确知道何时进程开始膨胀,然后在日志中跟踪它之前/正在发生的事情

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读