CPU 中央处理器调优

news2024/11/25 12:40:32

文章目录

- - 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请求上，所以运行队列里也有相当数个的可运行状态线程在等待执行.