Rails to monitor the process of memory leaks skills

Rails applications easier to encounter two types of performance problems: Rails implementation of a class are very slow, CPU consumption too high; The other is the process of memory leaks Rails. To resolve these two types of questions are necessary before you start you can pinpoint problems with the code, then we know how to prescribe the right medicine.

First, how the process of monitoring the implementation of the performance of Rails

Positioning high CPU consumption, the slow pace of implementation of the Rails code, is a very easy thing, you just need to do a little statistical analysis production.log, extracted the longest execution time of the request, the problem is evident. Production.log on Rails because of the execution of the request time to do the detailed statistics, such as:

Completed in 0.00693 (144 reqs/sec) | Rendering: 0.00489 (70%) | DB: 0.00000 (0%) | 200 OK [http://www.javaeye.com/]
Completed in 0.17238 (5 reqs/sec) | Rendering: 0.10011 (58%) | DB: 0.06244 (36%) | 200 OK [http://www.javaeye.com/topic/49441?page=7]
Completed in 0.20508 (4 reqs/sec) | Rendering: 0.19373 (94%) | DB: 0.00645 (3%) | 200 OK [http://www.javaeye.com/news/1586]

So we need to do is write a command line shell, they get! Him put the most time-consuming pre-screening of 500 requests out, save it to timing.log inside.

grep "200 OK" production.log | awk '{print "ALL: " $3 "  View: " $8 " DB: " $12 "  URL: " $17 }' \
| sort -r | head -n 500 > timing.log

Best to sort the results such as:

ALL: 5.51774  View: 5.38277 DB: 0.13338  URL: [http://www.javaeye.com/wiki/topic/131966]
ALL: 5.51316  View: 5.31300 DB: 0.19400  URL: [http://www.javaeye.com/wiki/topic/145383]
ALL: 5.51311  View: 5.39321 DB: 0.11234  URL: [http://www.javaeye.com/wiki/topic/160370]
ALL: 5.51135  View: 5.37604 DB: 0.12652  URL: [http://www.javaeye.com/wiki/topic/233365]
ALL: 5.49881  View: 5.35998 DB: 0.10637  URL: [http://www.javaeye.com/wiki/topic/265217]

Which requested the Executive of the slow, at a glance. In addition of course, we can real-time monitoring, surveillance in the top window displays the status of ongoing Rails request URL.

Second, how to monitor process memory leak Rails

CPU monitoring is a very easy thing, but the process of monitoring Rails memory leak is very difficult because there has not production.log Record changes in the process of memory, and even you can not find any ruby API can be used to direct inquiries to the process of physical memory used. In fact, it is necessary to obtain a process of physical memory are related to the operation of a platform, every operating system will be its own specific API, not generic, that is, the use of C language code, nor is it easy.

But for the Linux operating system, we have a shortcut to access the memory state of the process. Linux's / proc file system are kernel image, / proc / process pid / status file records the process status information, such as:

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

Attention to section 14 line VmRSS, Record of the process of physical memory used by the Permanent (Residence), this is actually occupied by the process of physical memory. So long as we read the first 14 lines of the document, you can get memory information.

Therefore become the U.S. mission: before proceeding with the request at Rails Record memory, such as Rails request processing, then record memory, the calculation of changes in memory, write to production.log go inside. Complete this work, we only need to Rails applications at app / controllers / application.rb inside to add a few lines of code:

  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

We define a AroundFilter, click Record deal with the request before and after changes in memory. With this information, we are the next things simple, just inside production.log extracted from this line of log, for statistical analysis can be, and this was only his party is only required to get a shell:

grep "CONSUME MEMORY" production.log | grep -v "CONSUME MEMORY: 0" |  \
 grep -v "CONSUME MEMORY: -" |  awk '{print $3 "\t" $6 "\t" $8 }' | sort -r -n | \
 head -n 500 > memory.log 

Record taken from memory, remove the memory does not increase, remove the memory reduction (taken place in GC) the request, and then, following a request to those who deal with the increase in memory records sorted out before the 500 record-keeping to the inside memory.log The results are as follows follows:

 Increase the number of memory footprint request URL
-----------------------------------------------
9528  175264  http://www.javaeye.com/topic/304594
9524  129512  http://knityster.javaeye.com/blog/172990
9496  147544  http://www.javaeye.com/forums/
9492  197800  http://duyiwuer.javaeye.com/rss
9452  146668  http://www.javaeye.com/forums
9452  133844  http://wildlife.javaeye.com/blog/47693
9440  157824  http://www.javaeye.com/rss/blogs
9424  204664  http://www.javaeye.com/wiki/topic/251964
9384  142200  http://towerhe.javaeye.com/blog/93704
9380  165372  http://www.javaeye.com/wiki/topic/77434
9368  207460  http://superleo.javaeye.com/rss

The first column are visited after a request, Rails process memory has increased by more than 9MB, the second column are processed the request, Rails process actual current accounts for more than 170 MB memory, the third column is the deal with what the request.

According to the statistical results, you can easily identify those that cause your Rails process memory leak culprit, and which you request to visit one of the Rails process memory on soaring thing is already clear at a glance, which is not very easy? In fact, through this approach, JavaEye took only half an hour, it solved the problem once more than half a year the memory leak problem, although the soil solution, very effective!

分类:Ruby 时间:2009-03-07 人气:3104
分享到:
blog comments powered by Disqus

相关文章

  • Flex application analysis and diagnosis of memory leaks 2010-11-05

    Back to Top Back to Top Back to Top Back to Top Back to Top Back to Top Development Suggestions to avoid memory leaks Let us recall the need to object known as a temporary object, then the essence, for the temporary object reference memory leak cause

  • Frequent distribution of free memory performance problems caused by the analysis of (Reprinted) 2010-03-29

    Phenomenon A pressure testing, found that the performance measured object is not ideal, the specific performance: CPU consumption of the system state process 20, the user mode CPU consumption of 10, the system idle about 70 2 Use the ps-o majflt, min

  • JAVA garbage collection and memory leaks 2010-07-20

    Since: http://apps.hi.baidu.com/share/detail/9064906 1. The core of garbage collection algorithm Java language to create a garbage collection mechanism to track the object being used and the discovery and recovery are no longer used (reference) objec

  • Performance analysis using IBM tools to solve performance problems in production environment 2010-04-19

    Yong-Feng Zhang, Software Engineer, IBM Yong-Feng Zhang IBM China Development Center is a software engineer. Description: Software system performance problem has always been a thorny issue can not be avoided, a successful software system that can del

  • Garbage collection on the Flex and memory leaks 2010-05-25

    In Java, we do not worry about memory problems, because Java can not automatically recover memory used, then the Flex has no similar mechanism for memory management (GC) do? Flex program run as a virtual machine (AVM), the garbage collection by the A

  • Class class loader on the issue of memory leaks 2010-07-29

    Since: http://blog.csdn.net/runanli/archive/2008/09/24/2972361.aspx Wave background and technical personnel for the Guangdong Tobacco Tobacco December 10 memory overflow events of a wide range of technology and get some constructive suggestions and c

  • developerWorks Book Channel: C + + application performance optimization, Chapter 6: Memory pool 2010-08-06

    Introduction This book is for C + + program performance optimization, in-depth C + + program performance optimization methods and examples. The book by the four papers formed the first one introduced C + + language, object model, the article is to op

  • Web 2.0 application client ten causes of performance problems 2010-08-27

    Web 2.0 applications for the users to promote a new experience, while giving developers more attention to client performance issues. Recently, senior Web performance diagnosis expert and founder of the Tools dynatrace Andreas Grabner according to the

  • ALTER TABLE in MySQL performance problems when 2010-03-15

    From: http://www.evget.com/zh-CN/Info/catalog/12561.html When a large table for ALTER TABLE when performance problems arise. MySQL most of the changes, follow these steps: Under the new table structure to create an empty table, the data from the old

iOS 开发

Android 开发

Python 开发

JAVA 开发

开发语言

PHP 开发

Ruby 开发

搜索

前端开发

数据库

开发工具

开放平台

Javascript 开发

.NET 开发

云计算

服务器

Copyright (C) codeweblog.com, All Rights Reserved.

CodeWeblog.com 版权所有 黔ICP备15002463号-1

processed in 0.252 (s). 12 q(s)