进程占用cpu资源过多负载高的原因分析及解决步骤

简介:

觉得写的非常好,以后会用到 ,所以转了过来,一切归原作者所有!

转自这里

服务器环境: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中的定义

 
 
  1. function getremotefile($file) { 
  2. global $_G; 
  3. @set_time_limit(0); 
  4. if(!@readfile($_G['setting']['ftp']['attachurl'].'forum/'.$file)) { 
  5. $ftp = ftpcmd('object'); 
  6. $tmpfile = @tempnam($_G['setting']['attachdir'], ''); 
  7. if($ftp->ftp_get($tmpfile, 'forum/'.$file, FTP_BINARY)) { 
  8. @readfile($tmpfile); 
  9. @unlink($tmpfile); 
  10. } else { 
  11. @unlink($tmpfile); 
  12. return FALSE; 
  13. return TRUE; 
  14. }  


没有对传入的参数作任何初步检查,而且设置了永不超时,并且使用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目录下) 

 
 
  1. #!/bin/bash 
  2. find /www/ -name "*.php" > list.txt 
  3.  
  4. f=`cat ./list.txt` 
  5.  
  6. for n in $f 
  7. do 
  8. r=`egrep 'view_time' $n` 
  9. if [ ! "$r" = "" ] ; then 
  10. echo $n 
  11. fi 
  12. done  

运行这个shell程序,将输出包含有view_time的文件, 对记事狗微博系统,产生的问题位于modules/topic.mod.class文件中

来自这里

 
  1. 大家好,公司有一台服务器上部署了mysql+php+apache! 
  2. 但是发现apache有一个httpd进程占用很高的cup,请教有没有什么命令能查看到时什么文件调用了这个进程? 
  3.  
  4. lsof -p 13321 

 

本文转自 dongnan 51CTO博客,原文链接:http://blog.51cto.com/dngood/692615


相关文章
|
28天前
|
消息中间件 Java 应用服务中间件
我是如何通过火焰图分析让应用CPU占用下降近20%的
分享作者在使用Arthas火焰图工具进行Java应用性能分析和优化的经验。
|
1月前
线程CPU异常定位分析
【10月更文挑战第3天】 开发过程中会出现一些CPU异常升高的问题,想要定位到具体的位置就需要一系列的分析,记录一些分析手段。
56 0
|
3月前
|
Linux
Linux源码阅读笔记10-进程NICE案例分析2
Linux源码阅读笔记10-进程NICE案例分析2
|
3月前
|
Linux
Linux源码阅读笔记09-进程NICE案例分析1
Linux源码阅读笔记09-进程NICE案例分析1
|
2天前
|
运维 JavaScript jenkins
鸿蒙5.0版开发:分析CppCrash(进程崩溃)
在HarmonyOS 5.0中,CppCrash指C/C++运行时崩溃,常见原因包括空指针、数组越界等。系统提供基于posix信号机制的异常检测能力,生成详细日志辅助定位。本文详解CppCrash分析方法,涵盖异常检测、问题定位思路及案例分析。
18 4
|
2天前
|
运维 监控 JavaScript
鸿蒙next版开发:分析JS Crash(进程崩溃)
在HarmonyOS 5.0中,JS Crash指未处理的JavaScript异常导致应用意外退出。本文详细介绍如何分析JS Crash,包括异常捕获、日志分析和典型案例,帮助开发者定位问题、修复错误,提升应用稳定性。通过DevEco Studio收集日志,结合HiChecker工具,有效解决JS Crash问题。
17 4
|
1月前
|
存储 安全 算法
CPU资源
【10月更文挑战第2天】CPU资源
64 5
|
1月前
|
NoSQL Linux 程序员
进程管理与运行分析
进程管理与运行分析
22 0
|
2月前
|
并行计算 API 调度
探索Python中的并发编程:线程与进程的对比分析
【9月更文挑战第21天】本文深入探讨了Python中并发编程的核心概念,通过直观的代码示例和清晰的逻辑推理,引导读者理解线程与进程在解决并发问题时的不同应用场景。我们将从基础理论出发,逐步过渡到实际案例分析,旨在揭示Python并发模型的内在机制,并比较它们在执行效率、资源占用和适用场景方面的差异。文章不仅适合初学者构建并发编程的基础认识,同时也为有经验的开发者提供深度思考的视角。
|
4月前
|
运维 监控 Linux
解决CPU与带宽高使用率问题:深入分析与应对策略
引言:性能问题的诊断与优化 在运维工作中,操作系统性能问题如影随形,典型代表是CPU使用率高和带宽使用率高的问题,它们直接影响应用的性能和响应时间。这篇记录将逐个分析这两个问题的产生原因和解决方法。
解决CPU与带宽高使用率问题:深入分析与应对策略

相关实验场景

更多
下一篇
无影云桌面