CentOS进程资源占用高原因分析命令

1、查看进程的线程：
ps -eLf|egrep ‘gateserver|UID‘

2、跟踪线程调用： 
strace  -p 15530

3、统计线程中函数的调用小号CPU时间：
strace  -p 16334 -c IT网.cn，http://www.it.net.cn 
strace  -p 15530 -o out.file #输出到out.file文件

4、只显示recv函数的调用:
strace  -p 5314 -f -F -e recv

5、gdb调试线程：
gdb  -p  pid

6、查看线程打开的文件描述符：

lsof  -p   pid

时间： 2024-11-09 01:55:34

CentOS进程资源占用高原因分析命令的相关文章

linux进程资源占用高原因分析命令记录

1.查看进程的线程: ps -eLf|egrep 'gateserver|UID' 2.跟踪线程调用: strace -p 15530 3.统计线程中函数的调用小号CPU时间: strace -p 16334 -c strace -p 15530 -o out.file #输出到out.file文件 4.只显示recv函数的调用: strace -p 5314 -f -F -e recv 5.gdb调试线程: gdb -p pid 6.查看线程打开的文件描述符: lsof -p pid

windows svhost 资源占用高

最近发现svhost总是一开机就占用大量资源(内存,CPU).经过一番百度,取其精华去其糟粕,简单总结一下一般怎么解决这个问题: 打开任务管理器,找到资源占用高的svhost进程的pid,假设是123 运行cmd(windows功能键+R,输入cmd并回车),输入命令:tasklist /svc | findstr "123".返回结果为对应的svhost进程相关的服务. 上百度查找这些服务对应的服务名称. 打开services.msc(windows功能键+R,输入services.

Java进程CPU占用高导致的网页请求超时的故障排查

一.发现问题的系统检查: 一个管理平台门户网页进统计页面提示请求超时,随进服务器操作系统检查load average超过4负载很大,PID为7163的进程占用到了800%多. 二.定位故障 根据这种故障的一般处理思路,先找出问题进程内CPU占用率高的线程,再通过线程栈信息找出该线程当时在运行的问题代码段,操作如下: 2.1.根据思路查看高占用的"进程中"占用高的"线程",追踪发现7163的进程中16298的线程占用较高,使用命令: top -Hbp 7163 | a

php-cgi进程占用cpu资源过大原因分析及解决

一,开启日志记录,为以后排查做准备 1.1 开启php-fpm.conf的错误日志和慢执行日志和常规日志, 采样一个小时,就可以根据这些日志的内容进行分析问题error_log = /tmp/error.log //错误日志access.log = /tmp/access.$pool.log //常规日志,记录每次访问时间,记录不同参数,以防止恶意攻击,后面会详细解析access.format = "%R – %u %t \"%m %r%Q%q\" %s %f %{mili}

java线程数过高原因分析

作者:鹿丸不会多项式  出处:http://www.cnblogs.com/hechao123   转载请先与我联系. 一.问题描述 前阵子我们因为B机房故障,将所有的流量切到了A机房,在经历了推送+自然高峰之后,A机房所有服务器都出现java线程数接近1000的情况(1000是设置的max值),在晚上7点多观察,java线程数略有下降,但还是有900+的样子,而此时,单台服务器的TPS维持在400/s,并不是一个特别大的量.然后将A机房一台机器下线,继续观察,到了晚上9点多,那台下线的机器,j

Centos查看端口占用和开启端口命令

Centos查看端口占用情况命令,比如查看80端口占用情况使用如下命令: lsof -i tcp:80 列出所有端口 netstat -ntlp 1.开启端口(以80端口为例) 方法一: /sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT 写入修改 /etc/init.d/iptables save 保存修改 service iptables restart 重启防火墙,修改生效 方法二: vi /etc/sysconfig/iptables

在Android library中不能使用switch-case语句访问资源ID的原因分析及解决方案

转:http://www.jianshu.com/p/89687f618837 原因分析   当我们在Android依赖库中使用switch-case语句访问资源ID时会报如下图所示的错误,报的错误是case分支后面跟的参数必须是常数,换句话说出现这个问题的原因是Android library中生成的R.java中的资源ID不是常数: 打开library中的R.java,发现确实如此,每一个资源ID都没有被声明为final: 但是当你打开你的主工程,在onClick.onItemClick等各种

mysql负载飙高原因分析

某些进程/服务消耗更多CPU资源(服务响应更多请求或存在某些应用瓶颈):发生比较严重的swap(可用物理内存不足):发生比较严重的中断(因为SSD或网络的原因发生中断):磁盘I/O比较慢(会导致CPU一直等待磁盘I/O请求): 绝对不要因表数据量小,sql语句随便写都行,随便join都不会出现性能瓶颈,决不能有这种思想.尽量避免join表 join表笛卡尔积如果要join表一定要把where条件写全,安全起见最好加个limit.一次请求读写的数据量太大,导致磁盘I/O读写值较大,例如一个SQL里

偶遇 smon 进程cpu 开销高异常分析

今天突然发现线上一台oracle 数据库 服务器cpu 跑的很高,感觉不是很正常,仔细看了下:发现是smon 进程吃掉了一个cpu. 那么这个smon 进程到底在倒腾啥玩意 对smon 进程开启10046 跟下不就全明了了么 分析trace 文件就这么一个sql语句 ,这玩意在删smon_scn_time delete from smon_scn_time where thread=0 and scn =  (select min(scn) from smon_scn_time where th