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)并制作一个简单的脚本,每分钟左右将内存使用转储到一个文件中(确保你没有填满你的磁盘) – 这将使你能够准确知道何时进程开始膨胀,然后在日志中跟踪它之前/正在发生的事情 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |