Rails应用比较容易遇到的两类性能问题：一类是Rails执行很慢，CPU消耗过高；另一类是Rails进程内存泄漏。解决这两类问题都需要你首先能够精确定位出现问题的代码，然后才知道如何对症下药。 一、如何监控Rails进程的执行性能 定位消耗CPU高，执行速度缓慢的Rails代码，是相当容易的事情，仅仅需要你对production.log做一点统计分析，抽取出来执行时间最长的请求，问题就昭然若揭了。由于production.log对Rails请求的执行时间做了详细的统计，例如： Completed in 0.00693 (144 reqs/sec) | Rendering: 0.00489 (70%) | DB: 0.00000 (0%) | 200 OK [http://www.iteye.com/] Completed in 0.17238 (5 reqs/sec) | Rendering: 0.10011 (58%) | DB: 0.06244 (36%) | 200 OK [http://www.iteye.com/topic/49441?page=7] Completed in 0.20508 (4 reqs/sec) | Rendering: 0.19373 (94%) | DB: 0.00645 (3%) | 200 OK [http://www.iteye.com/news/1586] 所以我们只需要写一行shell命令，就搞定了！他把最耗时的前500个请求筛选出来，保存到timing.log里面。 grep "200 OK" production.log | awk '{print "ALL: " $3 " View: " $8 " DB: " $12 " URL: " $17 }' \ | sort -r | head -n 500 > timing.log 排序好的结果例如： ALL: 5.51774 View: 5.38277 DB: 0.13338 URL: [http://www.iteye.com/wiki/topic/131966] ALL: 5.51316 View: 5.31300 DB: 0.19400 URL: [http://www.iteye.com/wiki/topic/145383] ALL: 5.51311 View: 5.39321 DB: 0.11234 URL: [http://www.iteye.com/wiki/topic/160370] ALL: 5.51135 View: 5.37604 DB: 0.12652 URL: [http://www.iteye.com/wiki/topic/233365] ALL: 5.49881 View: 5.35998 DB: 0.10637 URL: [http://www.iteye.com/wiki/topic/265217] 哪些请求执行的慢，一目了然。 当然除此之外，我们还可以实时监控，在top监视窗口显示Rails当前正在执行的请求URL。 二、如何监控Rails进程的内存泄漏 监控CPU是很容易的事情，但要监控Rails进程的内存泄漏，却非常困难，原因在于production.log里面并没有记录进程的内存变化状况，甚至你找不到任何ruby API可以用来直接查询到进程使用的物理内存。实际上，要获取一个进程的物理内存是一个平台相关的操作，每个操作系统都会自己特定的API，并不通用，即使用C语言来编码，也不是一件容易的事情。 不过对于Linux操作系统来说，我们有一个捷径可以获取进程的内存状况。Linux的/proc文件系统是内核的映象，/proc/进程pid/status 文件记录了这个进程的状态信息，例如： Name: dispatch.fcgi State: S (sleeping) SleepAVG: 135% Tgid: 26645 Pid: 26645 PPid: 1 TracerPid: 0 Uid: 1002 1002 1002 1002 Gid: 100 100 100 100 FDSize: 64 Groups: 14 16 17 33 100 VmSize: 245680 kB VmLck: 0 kB VmRSS: 209104 kB VmData: 205116 kB VmStk: 824 kB VmExe: 764 kB VmLib: 4220 kB Threads: 1 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 0000000002006e47 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 注意第14行VmRSS，记录了该进程使用的常驻物理内存(Residence)，这个就是该进程实际占用的物理内存了。因此只要我们读取该文件第14行，就可以得到内存信息。 所以我们的任务变成了：在Rails处理请求之前记录内存，等Rails处理完请求之后，再记录内存，计算内存的变化状况，写入到production.log里面去。完成这个工作，只需要我们在Rails应用的app/controllers/application.rb里面添加几行代码： around_filter :record_memory def record_memory process_status = File.open("/proc/#{Process.pid}/status") 13.times { process_status.gets } rss_before_action = process_status.gets.split[1].to_i process_status.close yield process_status = File.open("/proc/#{Process.pid}/status") 13.times { process_status.gets } rss_after_action = process_status.gets.split[1].to_i process_status.close logger.info("CONSUME MEMORY: #{rss_after_action - rss_before_action} \ KB\tNow: #{rss_after_action} KB\t#{request.url}") end 我们定义了一个AroundFilter，记录一下处理请求前后的内存变化。有了这个信息，我们接下来的事情就简单了，只需要从production.log里面抽取出来这行log，进行统计分析就可以了，这也仅仅只需要一行shell就搞定了： grep "CONSUME....
↧