Linux下高cpu解決方案，Linuxcpu解決方案

Linux下高cpu解決方案，Linuxcpu解決方案

昨天搞定了一個十萬火急的issue，客戶抱怨產品升級後系統會變慢和CPU使用率相當高，客戶脾氣很大，聲稱不盡快解決這個問題就退貨，弄得我們 R&D壓力很大，解決這個issue的任務分給了我，客戶是南非的一個公司，由於時差問題，我只好在家遠程解決問題，晚上8點半用 gotomeeting遠程到客戶電腦查看我們的系統，折騰了四個多小時，終於在凌晨時reproduce了這個high CPU，趕緊抓Log，用wireshark抓包，用gcore,gstack,strace和top保存了系統的相關輸出。在第2天分析了這些文件後， 找到了產品的bug，代碼的作者分配了10K的緩沖區，並想當然認為10K足以夠用，當然99%的情況下是夠用的，但是在這1%的情況下出現了問題，緩沖 區不幸被寫滿了，然後程序進入了死循環，導致high CPU。找到了問題了，fix就很容易了，客戶的脾氣也緩和了，fix很快就可以deliver給客戶。反思解決問題的過程，覺得這個分析過程具有可復用 性，值得總結一下。

1.用top命令查看哪個進程占用CPU高
gateway網關進程14094占用CPU高達891%，這個數值是進程內各個線程占用CPU的累加值。

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14094 root 15 0 315m 10m 7308 S 891% 2.2 1:49.01 gateway
20642 root 17 0 17784 4148 2220 S 0.5 0.8 2:39.96 microdasys
1679 root 18 0 10984 1856 1556 R 0.3 0.4 0:22.21 sshd
22563 root 18 0 2424 1060 800 R 0.3 0.2 0:00.03 top
1 root 18 0 2156 492 460 S 0.0 0.1 0:01.59 init

2.用top -H -p pid命令查看進程內各個線程占用的CPU百分比

#top -H -p 14094
top中可以看到有107個線程，但是下面9個線程占用CPU很高，下面以線程14086為主，分析其為何high CPU

PID USER PR NI VIRT RES SHR S %CPU MEM TIME+ COMMAND

14086 root 25 0 922m 914m 538m R 101 10.0 21:35.46 gateway

14087 root 25 0 922m 914m 538m R 101 10.0 10:50.22 gateway

14081 root 25 0 922m 914m 538m S 99 10.0 8:57.36 gateway

14082 root 25 0 922m 914m 538m R 99 10.0 11:51.92 gateway

14089 root 25 0 922m 914m 538m R 99 10.0 21:21.77 gateway

14092 root 25 0 922m 914m 538m R 99 10.0 19:55.47 gateway

14094 root 25 0 922m 914m 538m R 99 10.0 21:02.21 gateway

14083 root 25 0 922m 914m 538m R 97 10.0 21:32.39 gateway

14088 root 25 0 922m 914m 538m R 97 10.0 11:23.12 gateway

3.使用gstack命令查看進程中各線程的函數調用棧
#gstack 14094 > gstack.log
在gstack.log中查找線程ID14086，由於函數棧會暴露函數細節，因此只顯示了兩個函數桢，線程ID14086對應線程號是37

Thread 37 (Thread 0x4696ab90 (LWP 14086)):
#0 0x40000410 in __kernel_vsyscall ()
#1 0x40241f33 in poll () from /lib/i686/nosegneg/libc.so.6

4.使用gcore命令轉存進程映像及內存上下文

#gcore 14094
該命令生成core文件core.14094


5。用strace命令查看系統調用和花費的時間
#strace -T -r -c -p 14094

-c參數顯示統計信息，去掉此參數可以查看每個系統調用話費的時間及返回值。

% time seconds usecs/call calls errors syscall

------ ----------- ----------- --------- --------- ----------------------------

99.99 22.683879 3385 6702 poll

0.00 0.001132 0 6702 gettimeofday

0.00 0.000127 1 208 208 accept

0.00 0.000022 22 1 read

0.00 0.000000 0 1 write

0.00 0.000000 0 1 close

0.00 0.000000 0 14 time

0.00 0.000000 0 2 stat64

0.00 0.000000 0 4 clock_gettime

0.00 0.000000 0 7 send

0.00 0.000000 0 10 10 recvfrom

------ ----------- ----------- --------- --------- ------------------------------

100.00 22.685160 13652 218 total

6.用gdb調試core文件，並線程切換到37號線程
gcore和實際的core dump時產生的core文件幾乎一樣，只是不能用gdb進行某些動態調試

(gdb) gdb gateway core.14094
(gdb) thread 37
[Switching to thread 37 (Thread 0x4696ab90 (LWP 14086))]#0 0x40000410 in __kernel_vsyscall ()
(gdb) where
#0 0x40000410 in __kernel_vsyscall ()
#1 0x40241f33 in poll () from /lib/i686/nosegneg/libc.so.6
可以根據詳細的函數棧進行gdb調試，打印一些變量值，並結合源代碼分析為何會poll調用占用很高的CPU。
因為代碼涉及到公司產權，顧不在此做詳細分析，需要明白的是分析的流程和使用的命令。

流程為：進程ID->線程ID->線程函數調用棧->函數耗時和調用統計->源代碼分析

http://xxxxxx/Linuxjc/1180114.html TechArticle