标题：[实践OK]Linux上查看造成IO高负载的进程,进程占用某颗cpu资源过多负载高的原因分析及解决步骤 。
出处：向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
时间：Sat, 24 Jun 2017 13:01:50 +0000
作者：jackxiang
地址：http://jackxiang.com/post/9271/

内容：
背景：面对一个不熟悉上面所跑哪些应用的16核心机器，出现负载到56这样的情况，而通过top命令后按P看CPU高的，也并不高，此时，可以想到的是某个核心太高，因为top里面默认的值是平均值，16个核心平均下来其CPU使用效率并不高，鉴于此，得在top输出时按下1，然后定位到某个核心高，才能有的放矢的查看该CPU上跑了哪些应用，贴个简单的命令吧，具体实践排查详细过程在：

ps -eo 'psr pid pcpu command'|sort -k1 -n|grep -E '^ {1,2}(9|12|13|15) '|less  

实战，/usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf ：

ps -eo 'psr pid pcpu command'|sort -k1 -n|grep -E '^{5}'
  0 28167  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
  0 28168  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
  0 28717  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
  0 28718  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
  0 28740  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
  0 28741  0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
发现是Rsyncd进程引起的，于是杀死rsyncd进程：
ps aux|grep rsyncd|grep -v grep |awk '{print "kill -9 "$2}'|sh
用Top命令发现，CPU第0颗的负载太高，如下：
Tasks: 209 total,   1 running, 208 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 0.08%id,  99.2%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.1%sy,  0.0%ni, 96.8%id,  3.1%wa,  0.0%hi,  0.0%si,  0.0%st


Top命令下按1后第三行显示比较关键：
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,  0.0%id,100.0%wa,  0.0%hi,  0.0%si,  0.0%st
top命令的第三行“Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st”显示的内容依次为“用户空间占用CPU百分比”、“内核空间占用CPU百分比”、“用户空间内改变过优先级的进程占用CPU百分比”、“空闲CPU百分比”、“等待输入输出CPU时间百分比”、“CPU服务于硬件中断所耗费的时间总额”、“CPU服务软中断所耗费的时间总额”、“Steal Time”

Kipmi0 占用100% CPU1核：
https://yq.aliyun.com/articles/15198

方法1：使用iotop工具
这是一个python脚本工具，使用方法如：iotop -o


方法2：使用工具dmesg
使用dmesg之前，需要先开启内核的IO监控：
echo 1 >/proc/sys/vm/block_dump或sysctl vm.block_dump=1


然后可以使用如下命令查看IO最重的前10个进程：
dmesg |awk -F: '{print $1}'|sort|uniq -c|sort -rn|head -n 10


方法3：使用命令“iostat -x 1“确定哪个设备IO负载高:
# iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.06    0.00    0.99    1.09    0.00   97.85


Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          0.49  17.29  1.74  6.75   23.47  200.18    11.73   100.09    26.33     0.10   12.25   5.73   4.87


找“await”值最大的设备（Device），如上的结果即为sda。
​

然后使用mount找到sda挂载点，再使用fuser命令查看哪些进程在访问，如：
# fuser -vm /data

==================================================================================
进程占用cpu资源过多负载高的原因分析及解决步骤
2011-10-20 10:30:05
标签：负载高 nginx 休闲 apache linux
觉得写的非常好，以后会用到 ，所以转了过来，一切归原作者所有！
转自这里
服务器环境：redhat linux 5.5 , nginx , phpfastcgi 


在此环境下，一般php-cgi运行是非常稳定的，但也遇到过php-cgi占用太多cpu资源而导致服务器响应过慢，我所遇到的php-cgi进程占用cpu资源过多的原因有： 


1. 一些php的扩展与php版本兼容存在问题，实践证明 eAccelerater与某些php版本兼容存在问题，具体表现时启动php-cgi进程后，运行10多分钟，奇慢无比，但静态资源访问很快，服务器负载也很正常（说明nginx没有问题，而是php-cgi进程的问题），解决办法就是从php.ini中禁止掉eAccelerater模块，再重启 php-cgi进程即可 


2. 程序中可能存在死循环，导致服务器负载超高（使用top指令查看负载高达100+）, 需要借助Linux的proc虚拟文件系统找到具体的问题程序 


3. php程序不合理使用session , 这个发生在开源微博记事狗程序上，具体表现是有少量php-cgi进程（不超过10个）的cpu使用率达98%以上， 服务器负载在4-8之间，这个问题的解决，仍然需要借助Linux的proc文件系统找出原因。 


4. 程序中存在过度耗时且不可能完成的操作（还是程序的问题），例如discuz x 1.5的附件下载功能: source/module/forum/forum_attachement.php中的定义
function getremotefile($file) { 
global $_G; 
@set_time_limit(0); 
if(!@readfile($_G['setting']['ftp']['attachurl'].'forum/'.$file)) { 
$ftp = ftpcmd('object'); 
$tmpfile = @tempnam($_G['setting']['attachdir'], ''); 
if($ftp->ftp_get($tmpfile, 'forum/'.$file, FTP_BINARY)) { 
@readfile($tmpfile); 
@unlink($tmpfile); 
} else { 
@unlink($tmpfile); 
return FALSE; 
} 
} 
return TRUE; 
}  


没有对传入的参数作任何初步检查，而且设置了永不超时，并且使用readfile一次读取超大文件，就可能存在以下问题： 
A. 以http方式读取远程附件过度耗时 
B. FTP无法连接时，如何及时反馈出错误？ 
C. readfile是一次性读取文件加载到内存中并输出，当文件过大时，内存消耗惊人 


根据实验发现采用readfile一次性读取，内存消耗会明显增加，但是CPU的利用率会下降较多。如果采用分段读取的方式，内存消耗会稍微下降，而CPU占用却会明显上升。 


对discuz x 1.5的这个bug较好解决方法就是后台重新正确设置远程附件参数。 


以下是我逐步整理的故障排除步骤： 


1. 得到占用cpu资源过多的php-cgi进程的pid(进程id)， 使用top命令即可，如下图： 
经过上图，我们发现，有两个php-cgi进程的cpu资源占用率过高，pid分别是10059，11570，这一般都是程序优化不够造成，如何定位问题的php程序位置？ 


2. 找出进程所使用的文件 
/proc/文件系统保存在内存中，主要保存系统的状态，关键配置等等，而/proc/目录下有很多数字目录，就是进程的相关信息，如下图，我们看看进程10059正在使用哪些文件？ 
显然，使用了/home/tmp/sess_*文件，这明显是PHP的session文件， 我们查看这个session文件的内容为：view_time|123333312412 


到这里，我们已经可以怀疑是由于php程序写入一个叫view_time的session项而引起， 那么剩余的事件就是检查包含view_time的所有php文件，然后修改之（比如改用COOKIE），这实话， 这个view_time并非敏感数据，仅仅记录用户最后访问时间，实在没必要使用代价巨大的session, 而应该使用cookie。 


3. 找出有问题的程序，修改之 
使用vi编辑以下shell程序（假设网站程序位于/www目录下） 
#!/bin/bash 
find /www/ -name "*.php" > list.txt 

f=`cat ./list.txt` 

for n in $f 
do 
r=`egrep 'view_time' $n` 
if [ ! "$r" = "" ] ; then 
echo $n 
fi 
done  
运行这个shell程序，将输出包含有view_time的文件， 对记事狗微博系统，产生的问题位于modules/topic.mod.class文件中
来自这里
大家好，公司有一台服务器上部署了mysql+php+apache！ 
但是发现apache有一个httpd进程占用很高的cup，请教有没有什么命令能查看到时什么文件调用了这个进程？ 

lsof -p 13321 


http://blog.csdn.net/aquester/article/details/51557879
http://blog.chinaunix.net/uid-7934175-id-4013411.html


Generated by Jackxiang's Bo-blog 2.1.1 Release