<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://jackxiang.com/post//</link>
<title><![CDATA[[实践OK]Linux上查看造成IO高负载的进程,进程占用某颗cpu资源过多负载高的原因分析及解决步骤 。]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[Unix/LinuxC技术]]></category>
<pubDate>Sat, 24 Jun 2017 05:01:50 +0000</pubDate> 
<guid>http://jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	背景：面对一个不熟悉上面所跑哪些应用的16核心机器，出现负载到56这样的情况，而通过top命令后按P看CPU高的，也并不高，此时，可以想到的是某个核心太高，因为top里面默认的值是平均值，16个核心平均下来其CPU使用效率并不高，鉴于此，得在top输出时按下1，然后定位到某个核心高，才能有的放矢的查看该CPU上跑了哪些应用，贴个简单的命令吧，具体实践排查详细过程在：<br/><textarea name="code" class="php" rows="15" cols="100">
ps -eo &#039;psr pid pcpu command&#039;&#124;sort -k1 -n&#124;grep -E &#039;^ &#123;1,2&#125;(9&#124;12&#124;13&#124;15) &#039;&#124;less&nbsp;&nbsp;
</textarea><br/>实战，/usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf ：<br/><textarea name="code" class="php" rows="15" cols="100">
ps -eo &#039;psr pid pcpu command&#039;&#124;sort -k1 -n&#124;grep -E &#039;^&#123;5&#125;&#039;
&nbsp;&nbsp;0 28167&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
&nbsp;&nbsp;0 28168&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
&nbsp;&nbsp;0 28717&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
&nbsp;&nbsp;0 28718&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
&nbsp;&nbsp;0 28740&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
&nbsp;&nbsp;0 28741&nbsp;&nbsp;0.0 /usr/local/rsync/bin/rsync --daemon --config=/etc/rsyncd.conf
发现是Rsyncd进程引起的，于是杀死rsyncd进程：
ps aux&#124;grep rsyncd&#124;grep -v grep &#124;awk &#039;&#123;print &quot;kill -9 &quot;$2&#125;&#039;&#124;sh
用Top命令发现，CPU第0颗的负载太高，如下：
Tasks: 209 total,&nbsp;&nbsp; 1 running, 208 sleeping,&nbsp;&nbsp; 0 stopped,&nbsp;&nbsp; 0 zombie
Cpu0&nbsp;&nbsp;:&nbsp;&nbsp;0.0%us,&nbsp;&nbsp;0.0%sy,&nbsp;&nbsp;0.0%ni, 0.08%id,&nbsp;&nbsp;99.2%wa,&nbsp;&nbsp;0.0%hi,&nbsp;&nbsp;0.0%si,&nbsp;&nbsp;0.0%st
Cpu1&nbsp;&nbsp;:&nbsp;&nbsp;0.0%us,&nbsp;&nbsp;0.1%sy,&nbsp;&nbsp;0.0%ni, 96.8%id,&nbsp;&nbsp;3.1%wa,&nbsp;&nbsp;0.0%hi,&nbsp;&nbsp;0.0%si,&nbsp;&nbsp;0.0%st
</textarea><br/><br/>Top命令下按1后第三行显示比较关键：<br/>Cpu0&nbsp;&nbsp;:&nbsp;&nbsp;0.0%us,&nbsp;&nbsp;0.0%sy,&nbsp;&nbsp;0.0%ni,&nbsp;&nbsp;0.0%id,100.0%wa,&nbsp;&nbsp;0.0%hi,&nbsp;&nbsp;0.0%si,&nbsp;&nbsp;0.0%st<br/>top命令的第三行“Cpu(s):&nbsp;&nbsp;0.0%us,&nbsp;&nbsp;0.0%sy,&nbsp;&nbsp;0.0%ni,100.0%id,&nbsp;&nbsp;0.0%wa,&nbsp;&nbsp;0.0%hi,&nbsp;&nbsp;0.0%si,&nbsp;&nbsp;0.0%st”显示的内容依次为“用户空间占用CPU百分比”、“内核空间占用CPU百分比”、“用户空间内改变过优先级的进程占用CPU百分比”、“空闲CPU百分比”、“等待输入输出CPU时间百分比”、“CPU服务于硬件中断所耗费的时间总额”、“CPU服务软中断所耗费的时间总额”、“Steal Time”<br/><br/>Kipmi0 占用100% CPU1核：<br/>https://yq.aliyun.com/articles/15198<br/><br/>方法1：使用iotop工具<br/>这是一个python脚本工具，使用方法如：iotop -o<br/><br/><br/>方法2：使用工具dmesg<br/>使用dmesg之前，需要先开启内核的IO监控：<br/>echo 1 &gt;/proc/sys/vm/block_dump或sysctl vm.block_dump=1<br/><br/><br/>然后可以使用如下命令查看IO最重的前10个进程：<br/>dmesg &#124;awk -F: &#039;&#123;print $1&#125;&#039;&#124;sort&#124;uniq -c&#124;sort -rn&#124;head -n 10<br/><br/><br/>方法3：使用命令“iostat -x 1“确定哪个设备IO负载高:<br/># iostat -x 1 3<br/>avg-cpu:&nbsp;&nbsp;%user&nbsp;&nbsp; %nice %system %iowait&nbsp;&nbsp;%steal&nbsp;&nbsp; %idle<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1.06&nbsp;&nbsp;&nbsp;&nbsp;0.00&nbsp;&nbsp;&nbsp;&nbsp;0.99&nbsp;&nbsp;&nbsp;&nbsp;1.09&nbsp;&nbsp;&nbsp;&nbsp;0.00&nbsp;&nbsp; 97.85<br/><br/><br/>Device:&nbsp;&nbsp;&nbsp;&nbsp;rrqm/s wrqm/s&nbsp;&nbsp; r/s&nbsp;&nbsp; w/s&nbsp;&nbsp;rsec/s&nbsp;&nbsp;wsec/s&nbsp;&nbsp;&nbsp;&nbsp;rkB/s&nbsp;&nbsp;&nbsp;&nbsp;wkB/s avgrq-sz avgqu-sz&nbsp;&nbsp; await&nbsp;&nbsp;svctm&nbsp;&nbsp;%util<br/>sda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0.49&nbsp;&nbsp;17.29&nbsp;&nbsp;1.74&nbsp;&nbsp;6.75&nbsp;&nbsp; 23.47&nbsp;&nbsp;200.18&nbsp;&nbsp;&nbsp;&nbsp;11.73&nbsp;&nbsp; 100.09&nbsp;&nbsp;&nbsp;&nbsp;26.33&nbsp;&nbsp;&nbsp;&nbsp; 0.10&nbsp;&nbsp; 12.25&nbsp;&nbsp; 5.73&nbsp;&nbsp; 4.87<br/><br/><br/>找“await”值最大的设备（Device），如上的结果即为sda。<br/>​<br/><br/>然后使用mount找到sda挂载点，再使用fuser命令查看哪些进程在访问，如：<br/># fuser -vm /data<br/><br/>==================================================================================<br/>进程占用cpu资源过多负载高的原因分析及解决步骤<br/>2011-10-20 10:30:05<br/>标签：负载高 nginx 休闲 apache linux<br/>觉得写的非常好，以后会用到 ，所以转了过来，一切归原作者所有！<br/>转自这里<br/>服务器环境：redhat linux 5.5 , nginx , phpfastcgi <br/><br/><br/>在此环境下，一般php-cgi运行是非常稳定的，但也遇到过php-cgi占用太多cpu资源而导致服务器响应过慢，我所遇到的php-cgi进程占用cpu资源过多的原因有： <br/><br/><br/>1. 一些php的扩展与php版本兼容存在问题，实践证明 eAccelerater与某些php版本兼容存在问题，具体表现时启动php-cgi进程后，运行10多分钟，奇慢无比，但静态资源访问很快，服务器负载也很正常（说明nginx没有问题，而是php-cgi进程的问题），解决办法就是从php.ini中禁止掉eAccelerater模块，再重启 php-cgi进程即可 <br/><br/><br/>2. 程序中可能存在死循环，导致服务器负载超高（使用top指令查看负载高达100+）, 需要借助Linux的proc虚拟文件系统找到具体的问题程序 <br/><br/><br/>3. php程序不合理使用session , 这个发生在开源微博记事狗程序上，具体表现是有少量php-cgi进程（不超过10个）的cpu使用率达98%以上， 服务器负载在4-8之间，这个问题的解决，仍然需要借助Linux的proc文件系统找出原因。 <br/><br/><br/>4. 程序中存在过度耗时且不可能完成的操作（还是程序的问题），例如discuz x 1.5的附件下载功能: source/module/forum/forum_attachement.php中的定义<br/>function getremotefile($file) &#123; <br/>global $_G; <br/>@set_time_limit(0); <br/>if(!@readfile($_G[&#039;setting&#039;][&#039;ftp&#039;][&#039;attachurl&#039;].&#039;forum/&#039;.$file)) &#123; <br/>$ftp = ftpcmd(&#039;object&#039;); <br/>$tmpfile = @tempnam($_G[&#039;setting&#039;][&#039;attachdir&#039;], &#039;&#039;); <br/>if($ftp-&gt;ftp_get($tmpfile, &#039;forum/&#039;.$file, FTP_BINARY)) &#123; <br/>@readfile($tmpfile); <br/>@unlink($tmpfile); <br/>&#125; else &#123; <br/>@unlink($tmpfile); <br/>return FALSE; <br/>&#125; <br/>&#125; <br/>return TRUE; <br/>&#125;&nbsp;&nbsp;<br/><br/><br/>没有对传入的参数作任何初步检查，而且设置了永不超时，并且使用readfile一次读取超大文件，就可能存在以下问题： <br/>A. 以http方式读取远程附件过度耗时 <br/>B. FTP无法连接时，如何及时反馈出错误？ <br/>C. readfile是一次性读取文件加载到内存中并输出，当文件过大时，内存消耗惊人 <br/><br/><br/>根据实验发现采用readfile一次性读取，内存消耗会明显增加，但是CPU的利用率会下降较多。如果采用分段读取的方式，内存消耗会稍微下降，而CPU占用却会明显上升。 <br/><br/><br/>对discuz x 1.5的这个bug较好解决方法就是后台重新正确设置远程附件参数。 <br/><br/><br/>以下是我逐步整理的故障排除步骤： <br/><br/><br/>1. 得到占用cpu资源过多的php-cgi进程的pid(进程id)， 使用top命令即可，如下图： <br/>经过上图，我们发现，有两个php-cgi进程的cpu资源占用率过高，pid分别是10059，11570，这一般都是程序优化不够造成，如何定位问题的php程序位置？ <br/><br/><br/>2. 找出进程所使用的文件 <br/>/proc/文件系统保存在内存中，主要保存系统的状态，关键配置等等，而/proc/目录下有很多数字目录，就是进程的相关信息，如下图，我们看看进程10059正在使用哪些文件？ <br/>显然，使用了/home/tmp/sess_*文件，这明显是PHP的session文件， 我们查看这个session文件的内容为：view_time&#124;123333312412 <br/><br/><br/>到这里，我们已经可以怀疑是由于php程序写入一个叫view_time的session项而引起， 那么剩余的事件就是检查包含view_time的所有php文件，然后修改之（比如改用COOKIE），这实话， 这个view_time并非敏感数据，仅仅记录用户最后访问时间，实在没必要使用代价巨大的session, 而应该使用cookie。 <br/><br/><br/>3. 找出有问题的程序，修改之 <br/>使用vi编辑以下shell程序（假设网站程序位于/www目录下） <br/>#!/bin/bash <br/>find /www/ -name &quot;*.php&quot; &gt; list.txt <br/><br/>f=`cat ./list.txt` <br/><br/>for n in $f <br/>do <br/>r=`egrep &#039;view_time&#039; $n` <br/>if [ ! &quot;$r&quot; = &quot;&quot; ] ; then <br/>echo $n <br/>fi <br/>done&nbsp;&nbsp;<br/>运行这个shell程序，将输出包含有view_time的文件， 对记事狗微博系统，产生的问题位于modules/topic.mod.class文件中<br/>来自这里<br/>大家好，公司有一台服务器上部署了mysql+php+apache！ <br/>但是发现apache有一个httpd进程占用很高的cup，请教有没有什么命令能查看到时什么文件调用了这个进程？ <br/><br/>lsof -p 13321 <br/><br/><br/>http://blog.csdn.net/aquester/article/details/51557879<br/>http://blog.chinaunix.net/uid-7934175-id-4013411.html
]]>
</description>
</item><item>
<link>http://jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] [实践OK]Linux上查看造成IO高负载的进程,进程占用某颗cpu资源过多负载高的原因分析及解决步骤 。]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>