使用top查看进程维度的CPU负载

使用top查看进程维度的CPU负载

https://blog.csdn.net/u013985879/article/details/83055917 

步骤一、找到最耗CPU的进程

工具：top

方法1：

• 执行top -c ，显示进程运行信息列表
• 键入P (大写p)，进程按照CPU使用率排序

方法2.（ps -eo pid,pcpu | sort -n -k 2 ）

步骤二：找到最耗CPU的线程

工具：top

方法1：

• top -Hp 30045，显示一个进程的线程运行信息列表
• 键入P (大写p)，线程按照CPU使用率排序

方法2（ps H -eo pid,tid,pcpu | sort -n -k 3  ----进程号-线程号-CPU占用率）

步骤三：将线程PID转化为16进制

工具：printf

方法：printf “%x” 29813

如上图，29813 对应的16进制是0x7475

步骤四：查看堆栈，找到线程在干嘛

工具：pstack/jstack/grep

方法：jstack 30045| grep ‘0x7475’ -A90( 注：最后的-A90是日志行数，也可以输出为文本文件或使用其他数字 )

• 打印进程堆栈
• 通过线程id，过滤得到线程堆栈

 注意事项：

  如果提示 -bash: jstack: command not found，则可以找到jdk的目录，进入bin目录，

        在执行 ./jstack 进程号 | grep 16进制异常线程号 -A90 即可。

如果提示 well-known file is not secure，则是因为账号权限的问题。在/tmp/hsperfdata_$USER/目录，有一个以进程号命名的文件，当我们执行jmap或者jstack出现上叙信息时，先检查执行该命令的用户是否和hsperfdata_$USER这个文件所属的用户一致，如果不一致，切换至成一致再执行。执行：sudo -u 有权限的账号 ./jstack 进程号 | grep 16进制异常线程号 -A90 即可。

补充命令：
1.查看线程的详细信息：cat /proc/进程号/task/线程号/status

2. pstree -p pid

3.实时显示 top -H -p pid

4.查看该进程下所有的线程  ps -efL | grep pid

5.free内存信息  cat /proc/meminfo  (重点关注一下 proc 目录下文件)

6.查看内存  free 

 

第一行用全局角度描述系统使用的内存状况：

total——总物理内存  
used——已使用内存，一般情况这个值会比较大，因为这个值包括了cache+应用程序使用的内存
free——完全未被使用的内存
shared——应用程序共享内存
buffers——缓存，主要用于目录方面,inode值等（ls大目录可看到这个值增加）
cached——缓存，用于已打开的文件

注意：
total=used+free
used=buffers+cached (maybe add shared also)
 
第二行描述应用程序的内存使用：

前个值表示-buffers/cache——应用程序使用的内存大小，used减去缓存值
后个值表示+buffers/cache——所有可供应用程序使用的内存大小，free加上缓存值

注意
-buffers/cache=used-buffers-cached
+buffers/cache=free+buffers+cached

第三行表示swap的使用： 
used——已使用
free——未使用

7.使用vmstat查看系统维度的CPU负载 vmstat -n 1# -n 1 表示结果一秒刷新一次。

r： 表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程，所以，该数值越大，通常表示系统运行越慢。
us：用户模式消耗的 CPU 时间百分比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。
sy：内核模式消耗的 CPU 时间百分比。
wa：IO 等待消耗的 CPU 时间百分比。该值较高时，说明 IO 等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
id：处于空闲状态的 CPU 时间百分比。如果该值持续为 0，同时 sy 是 us 的两倍，则通常说明系统则面临着 CPU 资源的短缺