linux java cpu 使用率 linux 进程 cpu使用率

转载

mob64ca13faa4e6 2023-10-12 12:30:08

文章标签 linux java cpu 使用率 php 16进制时间间隔 文章分类 Java 后端开发

摘学习笔记

1、Linux并发(任务并行)的实质：Linux 作为一个多任务操作系统，将每个 CPU 的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用

2、cpu的维护，通过实先定义的节拍率(内核用赫兹HZ标示)触发时间判断(全局变量jiffies记录)。

3、节拍率是内核态运行，属于内核空间节拍率；用户空间节拍率( USER_HZ)是一个固定设置 [root@dbayang ~]# grep 'CONFIG_HZ=' /boot/config-$(uname -r) CONFIG_HZ=1000

4、/proc/stat 提供的就是系统的 CPU 和任务统计信息；

/proc/[pid]/stat展示进程的CPU和任务统计信息

5、cpu的使用率={1-(idle_time/total_cpu_time)}/sample_time

6、性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置。

top默认为3s，ps使用的是进程运行时间。

7、top、vmstat、mpstat等命令种关于cpu性能相关指标的含义

8、pidstat命令含义

9、perf 以前用到的一堆[n]trace分析工具，perf的直观易用。

perf top、

perf record、perf report 对进程进行跟踪分析其调用

perf top -g -p <mysqlpid>

10、今天用到测试工具：ab

针对“幽灵”进程的发掘：

1，在top中，可见用户态cpu使用率很高，但未见相关有问题的进程；

2，尝试pidstat 1 找出问题进程，无果；

3，再次top,从load average 可见负载高，shift + f ，然后选择以s (进程状态）排序，按R倒序，可见running的进程主要就是几个stress进程，观察发现，running的stress进程的pid一直在变化；

4，watch -d 'ps aux | grep stress | grep -v grep' 发现多个stress进程在不断生成，由R变S再变Z（由于watch的时间间隔是1秒，所以只是看到有多个stress进程，有的状态是R有的是S有的是Z，所以我推断其生命周期是如此）

5，进程Pid再不断变化，有以下两个原因：

5.1，进程在不断崩溃重启，如因为段错误，配置错误等，这时进程在退出后又被监控系统自动重启

5.2，这些都是短进程，即在应用内部通过exec调用外部命令。这些命令一般只运行很短的时间就会结束，很难用时间间隔长的工具，如top去发现

6，用pstress去找其父进程

7，发现是php容器，故查看php源码 # 拷贝源码到本地 $ docker cp phpfpm:/app . # grep 查找看看是不是有代码在调用 stress 命令 $ grep stress -r app

8，从源代码中找相关字段

9，stress -t 1 -d 1 是模拟IO压力的，但在之前的top中，未见%iowait异常；

10，通过代码中的判断字段，手动赋值访问 curl http://192.168.0.10:10000?verbose=1 Server internal error: Array ( [0] => stress: info: [19607] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd [1] => stress: FAIL: [19608] (563) mkstemp failed: Permission denied [2] => stress: FAIL: [19607] (394) <-- worker 19608 returned error 1 [3] => stress: WARN: [19607] (396) now reaping child worker processes [4] => stress: FAIL: [19607] (400) kill error: No such process [5] => stress: FAIL: [19607] (451) failed run completed in 0s )

11，从这里可以猜测，由于权限错误，大量的stress进程在启动时初始化失败，结合第4点，我认为CPU消耗在进程上下文切换，从vmstat可见cs由问题出现前的100多骤升并稳定维持在3000多 [root@master ~]

# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 9 0 0 6932288 2160 790400 0 0 20 24 44 71 8 5 87 0 0 8 0 0 6932784 2160 790560 0 0 0 0 4027 3512 71 27 3 0 0 11 0 0 6934920 2160 790488 0 0 0 0 4170 3646 72 28 1 0 0 但pidstat -w |grep stress 却未见异常，因为同名进程一直在更换，所以用pidstat -w在这里是不太适用的 [root@master ~]# pidstat -w 2 | grep stress 09:55:29 AM 1 18583 0.50 0.50 stress 09:55:29 AM 1 18584 0.50 0.50 stress 09:55:29 AM 1 18586 0.50 0.00 stress

其他JVM分析：

处理CPU高的流程如下（大数据，基本都是jvm）：