文章目录
- 1.1 CPU处理方式:
- 1.2 查看CPU一秒钟有多个切换多少次。
- 1.3 调整进程优先级使用更多CPU
- 1.4 CPU亲和力
- 1.5 CPU 性能监控
- 1.6 CPU 利用率比例分配:
1.1 CPU处理方式:
- 批处理,顺序处理请求。(切换次数少,吞吐量大)
- 分时处理。(如同"独占",吞吐量小)(时间片,把请求分为一个一个的时间片,一片一片的分给CPU处理)我们现在使用x86就是这种架构
- 实时处理
例:
批处理——以前的大型机(Mainframe)上所采用的系统,需要把一批程序事先写好(打孔纸带),然后计算得出结果
分时——现在流行的PC机和服务器都是采用这种运行模式,即把CPU的运行分成若干时间片分别处理不同的运算请求
实时——一般用于单片机上,比如电梯的上下控制,对于按键等动作要求进行实时处理
1.2 查看CPU一秒钟有多个切换多少次。
查看内核一秒钟中断CPU次数:
grep HZ /boot/config-6.6.0-28.0.0.34.oe2403.x86_64
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_MACHZ_WDT=m
下面是这些配置项的含义:
-
CONFIG_NO_HZ_COMMON=y
:启用无时钟滴答(No HZ)的通用部分。无时钟滴答是一种内核调度器优化,它减少了定时器中断的频率,从而减少了处理器的开销。 -
CONFIG_HZ_PERIODIC
和CONFIG_NO_HZ_IDLE
被注释掉了,这意味着它们没有被设置。CONFIG_HZ_PERIODIC
用于设置周期性时钟滴答,而CONFIG_NO_HZ_IDLE
用于设置空闲时钟滴答。 -
CONFIG_NO_HZ_FULL=y
:启用完全无时钟滴答模式。在这种模式下,当CPU处于空闲状态时,时钟滴答会被完全关闭,以节省能源。 -
CONFIG_NO_HZ=y
:启用无时钟滴答功能。 -
CONFIG_HZ_100
、CONFIG_HZ_250
和CONFIG_HZ_300
被注释掉了,这意味着它们没有被设置。这些选项用于设置内核时钟滴答频率,单位是赫兹(Hz)。例如,CONFIG_HZ_100
会设置时钟滴答频率为100Hz。 -
CONFIG_HZ_1000=y
:设置内核时钟滴答频率为1000Hz。 -
CONFIG_HZ=1000
:定义了时钟滴答频率为1000Hz。 -
CONFIG_MACHZ_WDT=m
:这是一个模块化的配置选项,用于启用一个高精度的看门狗定时器(Watchdog Timer),它通常用于系统监控和恢复。
这些配置项通常在Linux内核的.config
文件中设置,用于在编译内核之前配置内核的行为。不同的配置项会影响内核的性能、功耗和实时性。
1.3 调整进程优先级使用更多CPU
调整进程nice值,让进程使用更多的CPU
优先级控制:
nice值 #范围, -20 ~ 19 越小优先级越高 普通用户0-19
nice
作用:以什么优先级运行进程 。默认优先级是0
语法: nice -n 优先级数字 命令
例:
[root@localhost ~]# nice -n -5 vim a.txt # vim进程以-5级别运行
查看:
[root@localhost ~]# ps -axu | grep a.txt
root 3345 0.0 0.0 22116 2248 pts/0 S+ 13:56 0:00 grep --color=auto a.txt
[root@localhost ~]# top -p 3345
[root@localhost ~]# renice -n -21 24129 #检测一下范围: -20 - 19
24129: old priority 5, new priority -20
[root@localhost ~]# renice -n 20 24129
24129: old priority -20, new priority 19
1.4 CPU亲和力
taskset 作用:在多核情况下,可以认为指定一个进程在哪颗CPU上执行程序,减少进程在不同CPU之前切换的开销
安装:
[root@xuegod63 ~]# rpm -qf `which taskset `
util-linux-2.23.2-43.el7.x86_64
语法: taskset -c N 命令
例1:本机是4核CPU ,指定vim命令在第一个CPU上运行
[root@xuegod63 ~]# taskset -c 0 vim a.txt #1号CPU ID是0
[root@xuegod63 ~]# ps -axu | grep vim
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root 2614 1.3 0.2 143696 3332 pts/0 S+ 18:39 0:00 vim a.txt
[root@xuegod63 ~]# taskset -p 2614 # -p 要查看的进程ID
pid 2614's current affinity mask: 1 #CPU亲和力掩码,1代表第一个CPU核心
例2:查sshd进程运行在哪几个CPU上
[root@xuegod63 ~]# ps -axu | grep sshd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root 2030 0.0 0.0 64068 1140 ? Ss 18:26 0:00 /usr/sbin/sshd
[root@xuegod63 ~]# taskset -p 2030
pid 2030's current affinity mask: f #说明sshd在4颗CPU上随机进行切换。
说明:
Cpu ID 号码,对应的16进制数为:
CPU ID: 7 6 5 4 3 2 1 0
对应的10数为: 128 64 32 16 8 4 2 1
当前, 我的系统中cpu ID 的为(0,1,2,3)
pid 2030’s current affinity mask: f的值为cpu ID 16进制的值的和(1+2+4+8=f),转换成二进制为:1111
这个说明了(pid=2030)的这个sshd进程工作在cpu ID 分别为0,1,2,3这个四个cpu上面的切换。
注: 我们的CPU是4核心,所以taskset -c后可以跟: 0,1,2,3
例:指定vim c.txt 程序运行在第2和第4个CPU上
[root@xuegod63 ~]# taskset -c 1,3 vim b.txt
[root@xuegod63 ~]# ps -axu | grep vim
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root 6314 1.5 0.2 143612 3280 pts/1 S+ 14:41 0:00 vim b.txt
root 6317 0.0 0.0 103300 848 pts/2 S+ 14:41 0:00 grep vim
[root@xuegod63 ~]# taskset -p 6314
pid 6314's current affinity mask: a
a为十进制的10=2+8
注:在哪个CPU上运行,那一位就赋为1 。
1.5 CPU 性能监控
理解运行队列,利用率,上下文切换对怎样CPU 性能最优化之间的关系,早期提及到性能是相对于基准线数据的,在一些系统中,通常预期所达到的性能包括:
Run Queues 每个处理器应该运行队列不超过13 个线程.
例如: 一个双核处理器应该运行队列不要超过6 个
注:有两个特殊的进程永远在运行队列中待着:当前进程和空进程idle。
1.6 CPU 利用率比例分配:
如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是
65% 70% User Time #用户态
30% 35% System Time #内核态
0% 5% Idle Time #空闲
Context Switches 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,有大量的上下文切换是正常的。
实例1:持续的CPU 利用率
在这个例子中,这个系统的CPU被充分利用
[root@xuegod63 ~]# vmstat 1 10 # 本机为单核CPU,执行vmstat显示以下内容
procs --------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 130644 86244 609860 0 0 4 1 531 25 0 0 20 0 0
4 0 0 130620 86244 609860 0 0 0 0 638 62 0 0 14 0 0
2 0 0 130620 86244 609860 0 0 0 0 658 62 0 0 13 0 0
4 0 0 130620 86244 609860 0 0 0 0 688 62 0 0 11 0 0
注:
根据观察值,我们可以得到以下结论:
1、有大量的中断(in) 和较少的上下文切换(cs)。这意味着一个单一的进程正在大量使用cpu
2、进一步显示某单个应用,user time(us) 经常在86%或者更多。
执行top -》按P-》查看使用CPU最多的进程
3、运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
实例2:超负荷调度
在这个例子中,内核调度中的上下文切换处于饱和
#vmstat 1 #通过查看vmstat输出结果,分析当前系统中出现的问题
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 1282 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 1229 2 7 91 0
根据观察值,我们可以得到以下结论:
1、上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在:上下文切换线程.
2、大量的上下文切换将导致CPU 利用率不均衡,很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us). 说明磁盘比较慢,磁盘是瓶颈
3、因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数个的可运行状态线程在等待执行.