Ruby

探讨如何统计Ruby应用服务器使用内存方法

2015-10-14  本文已影响0人  rubyist518

最近在解决探针获取Ruby应用服务器的内存使用的情况,将解决的思路总结一下,希望对此感兴趣的伙伴一起探讨。

先对比应用服务器:PumaPassenger,下面对比这2个服务器内存统计,

Puma (2.13.4)

单进程模式:直接获取进程id: Process.pid


memory = `ps -o rss= #{Process.pid}`.to_f / 1024 #单位:MB

cluster模式:以启动2个worker进程为例:

从上面截图可以看到,Puma启动后会出现3个进程:1个master进程和2个worker进程。

内存的使用情况(见RSS列):


(109908 + 109868 + 7256 ).to_f / 1024 = 221.7109375 #单位:MB

而对于探针来说,一个探针实例是伴随进程一起启动的,也就说一个探针只能识别自己所在的进程id,那如何获取应用服务器使用的内存?我们用其中1个woker进程所在的进程组[PGID]看一下:(为啥不是父进程?, 见下文Passenger)

这3个进程都在相同的进程组里,而且进程组号为master的进程id,那我们就可以用这个信息获取应用服务器的所使用的内存:

  1. 得到1个worker进程id: Process.pid

  2. 获取所在进程组: Process.getpgrp

  3. 获取到进程组内所有的进程:


`ps -o pid= -g #{Process.getpgrp}`.split("\n")

4.累加进程组内进程内存和即为应用服务器使用内存:


pids.inject(0.0){|m, pid| m + memory(pid)}

Passenger (5.0.20)

启动Passenger后的Process信息:

对Passenger架构感兴趣的请移步到这儿.

查看一下worker所在进程组和父进程:

通过PPID可以看出

Passenger core —> Passenger AppPreloader —> Passenger RubyApp

三者为爷-父-子关系,当服务器请求量增大时AppPreloader会产生新的进程来响应请求,从而新的RubyApp进程的PPID即为AppPreloaderPID,这样看来就可以将同一个PPID的进程加起来得到应用服务器的内存?

由于Passenger会根据服务器的负载量动态调整进程数,当服务器请求量较小时,Passenger会kill多余的进程,会出现下面的情况:

AppPreloader也被Passenger杀掉了。原RubyApp进程的PPID变成了1。这时如果服务器的请求量增大,应用服务器进程会成为这样:

passener 4passener 4

Passenger core 产生新的AppPreloader进程,并且AppPreloader产生新的RubyApp进程,这时如果只用PPID统计应用服务器内存就会不准确,所以要统计Passenger的使用的内存还得通过累加在同一个进程组(PGID)的所有进程使用的内存和得到。

由于UnicornRainbows都与Puma的cluster模式[master+worker模式]类似,内存统计的方式可以参考上文的Puma。

总结:

由于Thin启动多个server后没有类似的特点,上面方法不适用于Thin,有好方法的伙伴们可以告知:smile:

在解决探针统计应用服务器的内存问题上,摸索出了上面的一条路子,如果小伙伴们有其他更好的方式,可以一起探讨一下。

上一篇 下一篇

猜你喜欢

热点阅读