最近在项目上遇到负载均衡过高的问题,分析好几天,还因此移植了一个CPU检测工具,后面在小二哥的指导找到了问题原因,小二哥有些读者应该会比较熟悉,之前发的微信滑动卡顿就是他分析的,他是一个非常厉害的android系统工程师。
我这个问题比较棘手的是平均负载过高的时候,CPU占用和IOwait都是正常的,所以我第一时间还去查了僵尸进程,把僵尸进程都干掉后,发现CPU平均负载还是很高,最后在小二哥的提示下研究了下D进程,最后解决问题。
使用命令
cat /proc/loadavg
6.00 6.00 6.00 1/721 5555
查看当前系统的平均负载,前三个数分别是 1分钟、5分钟、15分钟的平均进程数。第四个的分子是正在运行的进程数,分母是进程总数;最后一个最近运行的进程ID号。
或者使用
uptime
08:24:29 up 19:34, 0 users, load average: 6.00, 6.00, 6.00
命令查看平均负载
08:24:29 //当前时间
up 19:34 //运行时间
0 users //当前的用户数量
load average: 6.00, 6.00, 6.00 //分别是 1分钟、5分钟、15分钟的平均进程数
还可以使用下面这个命令查看
dumpsys cpuinfo
所以什么是平均负载?
简单来说,平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和 CPU 使用率并没有直接关系。
这里我先解释下,可运行状态和不可中断状态这俩词儿。所谓可运行状态的进程,是指正在使用 CPU 或者正在等待 CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态(Running 或 Runnable)的进程。
不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的 I/O 响应,也就是我们在 ps 命令中看到的 D 状态(Uninterruptible Sleep,也称为 Disk Sleep)的进程。
把CPU当作一座桥梁,当load 等于1的时候,桥梁上正好有足够的汽车在行驶,当load等于0.5的时候,桥梁上还非常宽松,当load 等于1.7时候,说明已经有超负荷的汽车需要通过桥梁了。
现实工作中,我们经常容易把平均负载和 CPU 使用率混淆,所以在这里,我也做一个区分。
可能你会疑惑,既然平均负载代表的是活跃进程数,那平均负载高了,不就意味着 CPU 使用率高吗?
我们还是要回到平均负载的含义上来,平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数。
所以,它不仅包括了正在使用 CPU 的进程,还包括等待 CPU 和等待 I/O 的进程。而 CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应。
比如:
CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的;I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一定很高;大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。
使用top命令查看cpu使用情况
Tasks: 250 total, 1 running, 242 sleeping, 0 stopped, 1 zombie
Mem: 2007724k total, 862320k used, 1145404k free, 18576k buffers
Swap: 1505788k total, 0k used, 1505788k free, 415260k cached
400%cpu 2%user 0%nice 1%sys 397%idle 0%iow 0%irq 0%sirq 0%host
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS
5645 root 20 0 6.4M 3.6M 2.9M R 2.3 0.1 0:00.46 top
515 system 18 -2 1.1G 153M 134M S 0.3 7.7 5:03.83 system_server
318 shell 20 0 12M 1.2M 1.0M S 0.3 0.0 0:37.92 adbd --root_seclabel=u:r:su:s0
5642 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/u9:1]
5638 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kworker/u8:2]
5614 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/u9:0]
可以看到cpu使用率不是很高
但是查看平均负载的时候,就很高
08:44:56 up 19:55, 0 users, load average: 6.00, 6.00, 6.00
我们是4核CPU,如果平均负载低于4.0就是比较正常的,现在已经远远高于4.0了。
先使用脚本抓取trace文件
get_trace.bat 文件
@echo off
adb root
adb wait-for-device
adb root
rem set size
adb shell "echo 16384 > /sys/kernel/debug/tracing/buffer_size_kb"
rem set or use debug method
adb shell "echo nop > /sys/kernel/debug/tracing/current_tracer"
rem set debug event
adb shell "echo 'sched_switch sched_wakeup sched_wakeup_new' > /sys/kernel/debug/tracing/set_event"
rem enable debug
rem adb shell "echo 1 > /sys/kernel/debug/tracing/tracing_enabled >nul 2>&1"
rem stop debug
adb shell "echo 0 > /sys/kernel/debug/tracing/tracing_on"
rem clear debug data
adb shell "echo > /sys/kernel/debug/tracing/trace"
rem wait user to start
echo press any key to start ...
pause
rem start debug
adb shell "echo 1 > /sys/kernel/debug/tracing/tracing_on"
rem wait user to stop
echo press any key to stop ...
pause
rem stop debug
adb shell "echo 0 > /sys/kernel/debug/tracing/tracing_on"
echo pull debug data start ...
adb pull /sys/kernel/debug/tracing/trace sys_ftrace_data
echo pull debug data end
pause
获取trace文件 sys_ftrace_data
。
通过谷歌浏览器打开地址
chrome://tracing/
导入刚才的文件
通过分析CPU的使用情况,发现CPU工作不是非常繁忙,这和从TOP上看到的情况是一样的。
首先要了解下什么是D进程
Linux进程状态
S (TASK_INTERRUPTIBLE),可中断的睡眠状态
D (TASK_UNINTERRUPTIBLE),不可中断的睡眠状态。
使用如下命令查看D进程的backtrace
echo w > proc/sysrq-trigger
关于 sysrq-trigger
的说明可以自行百度,可能会给你带来惊喜。
然后查看内核日志,可以看到如下关键信息
[ 6619.317533] (0)[1621:sh] task PC stack pid father
[ 6619.317562] (0)[1621:sh]GCPU D c0b6f590 0 25 2 0x00000000
[ 6619.317576] (0)[1621:sh]Backtrace:
[ 6619.317585] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.317609] (0)[1621:sh] r10:c1103948 r9:00000201 r8:c1103948 r7:c1103948
[ 6619.317627] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0b72e4c>] (schedule_timeout+0x178/0x264)
[ 6619.317644] (0)[1621:sh] r4:7fffffff r3:dc8ba692
[ 6619.317655] (0)[1621:sh][<c0b72cd4>] (schedule_timeout) from [<c0b71bfc>] (__down+0x78/0xc4)
[ 6619.317670] (0)[1621:sh] r10:c1103948 r9:00000201 r8:c1103948 r7:00000002
[ 6619.317687] (0)[1621:sh][<c0b71b84>] (__down) from [<c018d2d0>] (down+0x4c/0x60)
[ 6619.317705] (0)[1621:sh] r8:d038de88 r7:ffff1234 r6:c1103948 r5:d038ddcc
[ 6619.317721] (0)[1621:sh][<c018d284>] (down) from [<c070d630>] (KREE_ServSemaphoreDown+0x14/0x1c)
[ 6619.317740] (0)[1621:sh] r4:c0cc5fd8
[ 6619.317748] (0)[1621:sh][<c070d61c>] (KREE_ServSemaphoreDown) from [<c070bcf8>] (tz_service_call+0x74/0xc4)
[ 6619.317767] (0)[1621:sh][<c070bc84>] (tz_service_call) from [<c070bf30>] (KREE_TeeServiceCall+0xe8/0x290)
[ 6619.317781] (0)[1621:sh] r7:00000002 r6:00000001 r5:00000002 r4:00000000
[ 6619.317799] (0)[1621:sh][<c070be48>] (KREE_TeeServiceCall) from [<c070c120>] (kree_thread_function+0x48/0x64)
[ 6619.317814] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c070c0d8
[ 6619.317831] (0)[1621:sh][<c070c0d8>] (kree_thread_function) from [<c0148aec>] (kthread+0x114/0x12c)
[ 6619.317849] (0)[1621:sh] r5:d0354d40 r4:00000000
[ 6619.317862] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.317908] (0)[1621:sh]fuse_log D c0b6f590 0 78 2 0x00000000
[ 6619.317922] (0)[1621:sh]Backtrace:
[ 6619.317930] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.317945] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c0392b8c
[ 6619.317963] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0148aa8>] (kthread+0xd0/0x12c)
[ 6619.317977] (0)[1621:sh] r4:00000000 r3:cf9032c0
[ 6619.317989] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.318020] (0)[1621:sh]hang_detect D c0b6f590 0 124 2 0x00000000
[ 6619.318034] (0)[1621:sh]Backtrace:
[ 6619.318043] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.318137] (0)[1621:sh] r10:00000001 r9:c1102100 r8:df5ebb80 r7:c1103948
[ 6619.318162] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0b72e1c>] (schedule_timeout+0x148/0x264)
[ 6619.318180] (0)[1621:sh] r4:001cfb65 r3:00000000
[ 6619.318190] (0)[1621:sh][<c0b72cd4>] (schedule_timeout) from [<c01ad908>] (msleep+0x34/0x40)
[ 6619.318209] (0)[1621:sh] r10:00000000 r9:c116e0a4 r8:cfb7dedc r7:c116e158
[ 6619.318228] (0)[1621:sh][<c01ad8d4>] (msleep) from [<c0733f5c>] (hang_detect_thread+0x94/0x318)
[ 6619.318244] (0)[1621:sh] r5:c116e158 r4:c1483ba8
[ 6619.318255] (0)[1621:sh][<c0733ec8>] (hang_detect_thread) from [<c0148aec>] (kthread+0x114/0x12c)
[ 6619.318270] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c0733ec8
[ 6619.318286] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.318320] (0)[1621:sh]mt_gpufreq_inpu D c0b6f590 0 164 2 0x00000000
[ 6619.318333] (0)[1621:sh]Backtrace:
[ 6619.318340] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.318354] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c0512ebc
[ 6619.318370] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0148aa8>] (kthread+0xd0/0x12c)
[ 6619.318384] (0)[1621:sh] r4:00000000 r3:cf825e40
[ 6619.318395] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.318412] (0)[1621:sh]display_esd_che D c0b6f590 0 169 2 0x00000000
[ 6619.318424] (0)[1621:sh]Backtrace:
[ 6619.318432] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.318446] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c0620888
[ 6619.318463] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0148aa8>] (kthread+0xd0/0x12c)
[ 6619.318477] (0)[1621:sh] r4:00000000 r3:cfbfe580
[ 6619.318487] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.318510] (0)[1621:sh]entropy_thread D c0b6f590 0 182 2 0x00000000
[ 6619.318523] (0)[1621:sh]Backtrace:
[ 6619.318531] (0)[1621:sh][<c0b6f244>] (__schedule) from [<c0b6faa0>] (schedule+0x54/0xc4)
[ 6619.318545] (0)[1621:sh] r10:c1103948 r9:00020107 r8:c1103948 r7:c1103948
[ 6619.318562] (0)[1621:sh][<c0b6fa4c>] (schedule) from [<c0b72e4c>] (schedule_timeout+0x178/0x264)
[ 6619.318577] (0)[1621:sh] r4:7fffffff r3:dc8ba692
[ 6619.318587] (0)[1621:sh][<c0b72cd4>] (schedule_timeout) from [<c0b71bfc>] (__down+0x78/0xc4)
[ 6619.318602] (0)[1621:sh] r10:c1103948 r9:00020107 r8:c1103948 r7:00000002
[ 6619.318619] (0)[1621:sh][<c0b71b84>] (__down) from [<c018d2d0>] (down+0x4c/0x60)
[ 6619.318634] (0)[1621:sh] r8:ced01e68 r7:0000002d r6:c1103948 r5:ced01dac
[ 6619.318651] (0)[1621:sh][<c018d284>] (down) from [<c070d630>] (KREE_ServSemaphoreDown+0x14/0x1c)
[ 6619.318666] (0)[1621:sh] r4:c0cc5fd8
[ 6619.318674] (0)[1621:sh][<c070d61c>] (KREE_ServSemaphoreDown) from [<c070bcf8>] (tz_service_call+0x74/0xc4)
[ 6619.318689] (0)[1621:sh][<c070bc84>] (tz_service_call) from [<c070bf30>] (KREE_TeeServiceCall+0xe8/0x290)
[ 6619.318703] (0)[1621:sh] r7:00000002 r6:00000001 r5:00000003 r4:00000000
[ 6619.318720] (0)[1621:sh][<c070be48>] (KREE_TeeServiceCall) from [<c070e418>] (entropy_thread+0xfc/0x228)
[ 6619.318734] (0)[1621:sh] r10:00000000 r9:00000000 r8:00000000 r7:c1103948
[ 6619.318751] (0)[1621:sh][<c070e31c>] (entropy_thread) from [<c0148aec>] (kthread+0x114/0x12c)
[ 6619.318765] (0)[1621:sh] r7:c070e31c r6:00000000 r5:cf703080 r4:00000000
[ 6619.318781] (0)[1621:sh][<c01489d8>] (kthread) from [<c0108730>] (ret_from_fork+0x14/0x24)
[ 6619.318999] (0)[1621:sh]Sched Debug Version: v0.11, 4.4.146 #10
[ 6619.319008] (0)[1621:sh]ktime : 6619310.281712
[ 6619.319016] (0)[1621:sh]sched_clk : 6619318.998704
[ 6619.319024] (0)[1621:sh]cpu_clk : 6619318.998857
[ 6619.319032] (0)[1621:sh]jiffies : 1895794
[ 6619.319040] (0)[1621:sh]
[ 6619.319045] (0)[1621:sh]sysctl_sched
[ 6619.319052] (0)[1621:sh] .sysctl_sched_latency : 10.000000
[ 6619.319060] (0)[1621:sh] .sysctl_sched_min_granularity : 2.250000
[ 6619.319068] (0)[1621:sh] .sysctl_sched_wakeup_granularity : 2.000000
[ 6619.319076] (0)[1621:sh] .sysctl_sched_child_runs_first : 0
[ 6619.319084] (0)[1621:sh] .sysctl_sched_features : 36667
[ 6619.319091] (0)[1621:sh] .sysctl_sched_tunable_scaling : 0 (none)
[ 6619.319099] (0)[1621:sh]
从日志里面可以看到有6个进程属于D进程状态,这几个进程一直在等待事件,导致CPU负载过高,但是实际上又没有使用CPU,所以CPU使用率并不高。
使用命令查看我们系统的D进程
为了验证上面的说话,我们需要把系统中的D进程干掉再继续查看CPU负载。
display_esd_che
这个进程看起来是和ESD静电相关,可能在屏幕死掉后才会被触发,这个是内核线程,所以我修改了内核代码,重新烧录再查看CPU负载。
0:/ # uptime
17:55:09 up 1:11, 0 users, load average: 3.09, 3.08, 3.12
可以明显看到CPU负载已经变低了,我们是4核CPU,平均负载低于4.0就属于正常。
top 可以查看系统CPU的状态,以百分比的形式显示出来。
Tasks: 251 total, 1 running, 243 sleeping, 0 stopped, 1 zombie
Mem: 2007724k total, 862108k used, 1145616k free, 18560k buffers
Swap: 1505788k total, 0k used, 1505788k free, 415260k cached
400%cpu 16%user 0%nice 6%sys 377%idle 0%iow 0%irq 0%sirq 0%host
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS
5628 root 20 0 5.9M 3.1M 2.7M R 19.3 0.1 0:00.07 top
5614 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/u9:0]
5609 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kworker/3:2]
5607 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kworker/u8:2]
5590 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/u9:4]
5585 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kworker/u8:3]
5577 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/u9:2]
5571 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kworker/3:0]
5537 root 20 0 0 0 0 S 0.0 0.0 0:00.05 [kworker/u8:1]
5448 root 20 0 0 0 0 S 0.0 0.0 0:00.67 [kworker/3:1]
us(user cpu time):用户态使用的cpu时间比。该值较高时,说明用户进程消耗的 CPU 时间比较多,比如,如果该值长期超过 50%,则需要对程序算法或代码等进行优化。
sy(system cpu time):系统态使用的cpu时间比。
ni(user nice cpu time):用做nice加权的进程分配的用户态cpu时间比
id(idle cpu time):空闲的cpu时间比。如果该值持续为0,同时sy是us的两倍,则通常说明系统则面临着 CPU 资源的短缺。
wa(wait):等待使用CPU的时间。
hi(hardware irq):硬中断消耗时间
si(software irq):软中断消耗时间
st(steal time):虚拟机偷取时间
vmstat用来检测系统的状态,包括CPU和内存,非常方便系统调试使用。
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 1146440 18564 415260 0 0 2 1 0 95 0 0 100 0
0 0 0 1146476 18564 415260 0 0 0 0 0 384 0 0 100 0
0 0 0 1146104 18564 415260 0 0 0 0 0 375 0 0 100 0
0 0 0 1146724 18564 415260 0 0 0 0 0 387 0 0 100 0
0 0 0 1146848 18564 415260 0 0 0 0 0 369 0 0 100 0
类别 | 项目 | 含义 | 说明 |
---|---|---|---|
Procs**(进程)** | r | 等待执行的任务数 | 展示了正在执行和等待cpu资源的任务个数。当这个值超过了cpu个数,就会出现cpu瓶颈。 |
B | 等待IO的进程数量 | ||
Memory(内存) | swpd | 正在使用虚拟的内存大小,单位k | |
free | 空闲内存大小 | ||
buff | 已用的buff大小,对块设备的读写进行缓冲 | ||
cache | 已用的cache大小,文件系统的cache | ||
inact | 非活跃内存大小,即被标明可回收的内存,区别于free和active | 具体含义见:概念补充(当使用-a选项时显示) | |
active | 活跃的内存大小 | 具体含义见:概念补充(当使用-a选项时显示) | |
Swap | si | 每秒从交换区写入内存的大小(单位:kb/s) | |
so | 每秒从内存写到交换区的大小 | ||
IO | bi | 每秒读取的块数(读磁盘) | 块设备每秒接收的块数量,单位是block,这里的块设备是指系统上所有的磁盘和其他块设备,现在的Linux版本块的大小为1024bytes |
bo | 每秒写入的块数(写磁盘) | 块设备每秒发送的块数量,单位是block | |
system | in | 每秒中断数,包括时钟中断 | 这两个值越大,会看到由内核消耗的cpu时间sy会越多 秒上下文切换次数,例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目 |
cs | 每秒上下文切换数 | ||
CPU**(以百分比表示)** | us | 用户进程执行消耗cpu时间(user time) | us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期超过50%的使用,那么我们就该考虑优化程序算法或其他措施了 |
sy | 系统进程消耗cpu时间(system time) | sys的值过高时,说明系统内核消耗的cpu资源多,这个不是良性的表现,我们应该检查原因。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足 | |
Id | 空闲时间(包括IO等待时间) | 一般来说 us+sy+id=100 | |
wa | 等待IO时间 | wa过高时,说明io等待比较严重,这可能是由于磁盘大量随机访问造成的,也有可能是磁盘的带宽出现瓶颈。 |
这个命令在Android上是没有的,我在github上找到了个半成品,编译了出来安装到我们的设备上
https://github.com/weiqifa0/pidstat/blob/main/README.md
pidstat主要用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。pidstat首次运行时显示自系统启动开始的各项统计信息,之后运行pidstat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。
常用参数:
-C comm #只显示那些包含字符串(可是正则表达式)comm的命令的名字
-d #显示I/O统计信息(须内核2.6.20及以后)
PID #进程号
kB_rd/s #每秒此进程从磁盘读取的千字节数
kB_wr/s #此进程已经或者将要写入磁盘的每秒千字节数
kB_ccwr/s #由任务取消的写入磁盘的千字节数
Command #命令的名字
-h #显示所有的活动的任务
-I #在SMP环境,指出任务的CPU使用(等同于选项-u)应该被除于cpu的总数
-l #显示进程的命令名和它的参数
-p { pid [,...] | SELF | ALL } #指定线程显示其报告
-r #显示分页错误的内存利用率
When reporting statistics for individual tasks, the following values are displayed:
PID #进程号
minflt/s #每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数
majflt/s #每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生
VSZ #该进程使用的虚拟内存(以kB为单位)
RSS #该进程使用的物理内存(以kB为单位)
%MEM #当前任务使用的有效内存的百分比
Command #任务的命令名
When reporting global statistics for tasks and all their children, the following values are displayed:
PID #PID号
minflt-nr #在指定的时间间隔内收集的进程和其子进程的次缺页错误次数
majflt-nr #在指定的时间间隔内收集的进程和其子进程的主缺页错误次数
Command #命令名
-s #堆栈的使用
-t #显示与所选任务相关的线程的统计数据
-T { TASK | CHILD | ALL } #指定必须监测的内容:TASK是默认的,单个任务的报告;CHILD:指定的进程和他们的子进程的全局报告,ALL:相当于TASK和CHILD
-u #报告CPU使用
When reporting statistics for individual tasks, the following values are displayed:
PID
%usr #用户层任务正在使用的CPU百分比(with or without nice priority ,NOT include time spent running a virtual processor)
%system #系统层正在执行的任务的CPU使用百分比
%guest #运行虚拟机的CPU占用百分比
%CPU #所有的使用的CPU的时间百分比
CPU #处理器数量
Command #命令
When reporting global statistics for tasks and all their children, the following values are displayed:
PID #PID号
usr-ms #在指定时间内收集的在用户层执行的进程和它的子进程占用的CPU时间(毫秒){with or without nice priority,NOT include time spent running a virtual processor)
system-ms #在指定时间内收集的在系统层执行的进程和它的子进程占用的CPU时间(毫秒)
guest-ms #花在虚拟机上的时间
Command #命令
-V #版本号
-w #报告任务切换情况
PID #PID号
cswch/s #每秒自动上下文切换
nvcswch/s #每秒非自愿的上下文切换
Command #命令
ps -A -o stat,ppid,pid,cmd | grep -e '^[Zz]'
https://blog.csdn.net/qq_23864697/article/details/110671859
好了,放下小二哥的公众号,喜欢安卓技术的可以勾搭他,喜欢篮球的也可以。
推荐阅读:
关注公众号,后台回复「1024」获取学习资料网盘链接。
欢迎点赞,关注,转发,在看,您的每一次鼓励,我都将铭记于心~
文章浏览阅读645次。这个肯定是末尾的IDAT了,因为IDAT必须要满了才会开始一下个IDAT,这个明显就是末尾的IDAT了。,对应下面的create_head()代码。,对应下面的create_tail()代码。不要考虑爆破,我已经试了一下,太多情况了。题目来源:UNCTF。_攻防世界困难模式攻略图文
文章浏览阅读2.9k次,点赞3次,收藏10次。偶尔会用到,记录、分享。1. 数据库导出1.1 切换到dmdba用户su - dmdba1.2 进入达梦数据库安装路径的bin目录,执行导库操作 导出语句:./dexp cwy_init/[email protected]:5236 file=cwy_init.dmp log=cwy_init_exp.log 注释: cwy_init/init_123..._达梦数据库导入导出
文章浏览阅读1.9k次。1. 在官网上下载KindEditor文件,可以删掉不需要要到的jsp,asp,asp.net和php文件夹。接着把文件夹放到项目文件目录下。2. 修改html文件,在页面引入js文件:<script type="text/javascript" src="./kindeditor/kindeditor-all.js"></script><script type="text/javascript" src="./kindeditor/lang/zh-CN.js"_kindeditor.js
文章浏览阅读2.3k次,点赞6次,收藏14次。SPI的详情简介不必赘述。假设我们通过SPI发送0xAA,我们的数据线就会变为10101010,通过修改不同的内容,即可修改SPI中0和1的持续时间。比如0xF0即为前半周期为高电平,后半周期为低电平的状态。在SPI的通信模式中,CPHA配置会影响该实验,下图展示了不同采样位置的SPI时序图[1]。CPOL = 0,CPHA = 1:CLK空闲状态 = 低电平,数据在下降沿采样,并在上升沿移出CPOL = 0,CPHA = 0:CLK空闲状态 = 低电平,数据在上升沿采样,并在下降沿移出。_stm32g431cbu6
文章浏览阅读1.2k次,点赞2次,收藏8次。数据链路层习题自测问题1.数据链路(即逻辑链路)与链路(即物理链路)有何区别?“电路接通了”与”数据链路接通了”的区别何在?2.数据链路层中的链路控制包括哪些功能?试讨论数据链路层做成可靠的链路层有哪些优点和缺点。3.网络适配器的作用是什么?网络适配器工作在哪一层?4.数据链路层的三个基本问题(帧定界、透明传输和差错检测)为什么都必须加以解决?5.如果在数据链路层不进行帧定界,会发生什么问题?6.PPP协议的主要特点是什么?为什么PPP不使用帧的编号?PPP适用于什么情况?为什么PPP协议不_接收方收到链路层数据后,使用crc检验后,余数为0,说明链路层的传输时可靠传输
文章浏览阅读587次。软件测试工程师移民加拿大 无证移民,未受过软件工程师的教育(第1部分) (Undocumented Immigrant With No Education to Software Engineer(Part 1))Before I start, I want you to please bear with me on the way I write, I have very little gen...
文章浏览阅读304次。Thinkpad X250笔记本电脑,装的是FreeBSD,进入BIOS修改虚拟化配置(其后可能是误设置了安全开机),保存退出后系统无法启动,显示:secure boot failed ,把自己惊出一身冷汗,因为这台笔记本刚好还没开始做备份.....根据错误提示,到bios里面去找相关配置,在Security里面找到了Secure Boot选项,发现果然被设置为Enabled,将其修改为Disabled ,再开机,终于正常启动了。_安装完系统提示secureboot failure
文章浏览阅读10w+次,点赞93次,收藏352次。1、用strtok函数进行字符串分割原型: char *strtok(char *str, const char *delim);功能:分解字符串为一组字符串。参数说明:str为要分解的字符串,delim为分隔符字符串。返回值:从str开头开始的一个个被分割的串。当没有被分割的串时则返回NULL。其它:strtok函数线程不安全,可以使用strtok_r替代。示例://借助strtok实现split#include <string.h>#include <stdio.h&_c++ 字符串分割
文章浏览阅读2.3k次。1 .高斯日记 大数学家高斯有个好习惯:无论如何都要记日记。他的日记有个与众不同的地方,他从不注明年月日,而是用一个整数代替,比如:4210后来人们知道,那个整数就是日期,它表示那一天是高斯出生后的第几天。这或许也是个好习惯,它时时刻刻提醒着主人:日子又过去一天,还有多少时光可以用于浪费呢?高斯出生于:1777年4月30日。在高斯发现的一个重要定理的日记_2013年第四届c a组蓝桥杯省赛真题解答
文章浏览阅读851次,点赞17次,收藏22次。摘要:本文利用供需算法对核极限学习机(KELM)进行优化,并用于分类。
文章浏览阅读1.1k次。一、系统弱密码登录1、在kali上执行命令行telnet 192.168.26.1292、Login和password都输入msfadmin3、登录成功,进入系统4、测试如下:二、MySQL弱密码登录:1、在kali上执行mysql –h 192.168.26.129 –u root2、登录成功,进入MySQL系统3、测试效果:三、PostgreSQL弱密码登录1、在Kali上执行psql -h 192.168.26.129 –U post..._metasploitable2怎么进入
文章浏览阅读257次。本文将为初学者提供Python学习的详细指南,从Python的历史、基础语法和数据类型到面向对象编程、模块和库的使用。通过本文,您将能够掌握Python编程的核心概念,为今后的编程学习和实践打下坚实基础。_python人工智能开发从入门到精通pdf