背景：面对一个不熟悉上面所跑哪些应用的16核心机器，出现负载到56这样的情况，而通过top命令后按P看CPU高的，也并不高，此时，可以想到的是某个核心太高，因为top里面默认的值是平均值，16个核心平均下来其CPU使用效率并不高，鉴于此，得在top输出时按下1，然后定位到某个核心高，才能有的放矢的查看该CPU上跑了哪些应用，贴个简单的命令吧，具体实践排查详细过程在：
实战，/usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf ：
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
实战，/usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf ：
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
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/9271/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2021-12-8 23:45
Linux系统自带的密码生成器——mkpasswd,Linux字符串md
linux 下 CLOSE_WAIT过多的解决方法，如果判定结论是僵尸进评论列表
