1、CPU处理方式
1.1 批处理,顺序处理请求。(切换次数少,吞吐量大)
批处理——以前的大型机(Mainframe)上所采用的系统,需要把一批程序事先写好(打孔纸带),然后计算得出结果
1.2 分时处理。(如同"独占",吞吐量小)(时间片,把请求分为一个一个的时间片,一片一片的分给CPU处理)我们现在使用x86就是这种架构
分时——现在流行的PC机和服务器都是采用这种运行模式,即把CPU的运行分成若干时间片分别处理不同的运算请求
1.3 实时处理
实时——一般用于单片机上,比如电梯的上下控制,对于按键等动作要求进行实时处理
2、查看内核一秒钟中断CPU次数
[root@docker-01 ~]# grep HZ /boot/config-3.10.0-957.el7.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_FULL_ALL is not set
CONFIG_NO_HZ=y
# CONFIG_RCU_FAST_NO_HZ is not set
# 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
3、调整进程优先级使用更多CPU
调整进程nice值,让进程使用更多的CPU
优先级控制:
nice值 #范围, -20 ~ 19 越小优先级越高 普通用户0-19
nice
作用:以什么优先级运行进程 。默认优先级是0
语法: nice -n 优先级数字 命令
[root@docker-01 scripts]# nice -n -5 vim a.txt ##vim进程以-5级别运行
[root@docker-01 ~]# ps -axu | grep a.txt
root 49588 0.0 0.0 151576 5112pts/0 S<+ 18:05 0:00 vima.txt
root 49614 0.0 0.0 112724 1004pts/1 S+ 18:05 0:00 grep--color=auto a.txt
[root@docker-01 ~]# top -p 49588
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+COMMAND
49588root 15 -5 151576 5112 2748S 0.0 0.0 0:00.02 vim
renice #修改正在运行的进程的优先级
#renice -n 5 PID #修改进程优先级
[root@docker-01 ~]# renice -n 5 49588
49588(进程 ID) 旧优先级为 -5,新优先级为 5
[root@docker-01 ~]# top -p 49588
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+COMMAND
49588root 25 5 151576 5112 2748S 0.0 0.0 0:00.02 vim
检测一下范围: -20 - 19
[root@docker-01 ~]# renice -n -21 49588
49588(进程 ID) 旧优先级为 5,新优先级为 -20
[root@docker-01 ~]# renice -n 20 49588
49588(进程 ID) 旧优先级为 -20,新优先级为 19
4、CPU亲和力
taskset 作用:在多核情况下,可以认为指定一个进程在哪颗CPU上执行程序,减少进程在不同CPU之前切换的开销
语法: taskset -c N 命令
4.1本机是4核CPU ,指定vim命令在第一个CPU上运行
[root@docker-01 scripts]# taskset -c 0 vim a.txt
[root@docker-01 scripts]# ps -axu | grep vim
root 49665 0.6 0.0 151576 5108pts/0 S+ 18:19 0:00 vima.txt
root 49667 0.0 0.0 112724 984pts/1 S+ 18:19 0:00 grep--color=auto vim
[root@docker-01 scripts]# taskset -p 49665
pid 49665's current affinity mask: 1 ##CPU亲和力掩码,1代表第一个CPU核心
4.2查sshd进程运行在哪几个CPU上
[root@docker-01 scripts]# ps -axu | grep sshd
root 3537 0.0 0.0 112756 4348? Ss 10月15 0:00 /usr/sbin/ssh -D
root 49454 0.0 0.0 154548 5536? Ss 17:59 0:00 sshd: root@pts/0
root 49589 0.0 0.0 154548 5536? Ss 18:05 0:00 sshd: root@pts/1
root 49689 0.0 0.0 112728 988pts/1 S+ 18:23 0:00 grep--color=auto sshd
[root@docker-01 scripts]# taskset -p 3537
pid 3537'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
4.3指定vim c.txt 程序运行在第2和第4个CPU上
[root@docker-01 scripts]# taskset -c 1,3 vim b.txt
[root@docker-01 scripts]# ps -axu | grep vim
root 49706 0.1 0.0 151532 5052pts/0 S+ 18:30 0:00 vimb.txt
root 49716 0.0 0.0 112724 980pts/1 S+ 18:30 0:00 grep--color=auto vim
[root@docker-01 scripts]# taskset -p 49706
[root@docker-01 scripts]# taskset -p 49706
pid 49706's current affinity mask: a ## a为十进制的10=2+8
注:在哪个CPU上运行,那一位就赋为1 。
5、CPU 利用率比例分配
如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是
65% 70% User Time #用户态
30% 35% System Time #内核态
0% 5% Idle Time #空闲
Context Switches 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,有大量的上下文切换是正常的。
5.1持续的CPU 利用率
[root@docker-01 ~]# vmstat 1 10 ##本机为4核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 86244609860 0 0 4 1 531 250 0 20 0 0
4 0 0 130620 86244609860 0 0 0 0 638 620 0 14 0 0
2 0 0 130620 86244609860 0 0 0 0 658 620 0 13 0 0
4 0 0 130620 86244609860 0 0 0 0 688 620 0 11 0 0
注:
根据观察值,我们可以得到以下结论:
1.有大量的中断(in) 和较少的上下文切换(cs)。这意味着一个单一的进程正在大量使用cpu.
2.进一步显示某单个应用,user time(us) 经常在86%或者更多.
执行top -》按P-》查看使用CPU最多的进程.
3.运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
5.2超负荷调度
[root@docker-01 ~]# 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
注:
根据观察值,我们可以得到以下结论:
1.上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在:上下文切换线程.
2.大量的上下文切换将导致CPU 利用率不均衡,很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us). 说明磁盘比较慢,磁盘是瓶颈.
3、因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数个的可运行状态线程在等待执行.
打印一则招聘信息:自己的朋友目前在找UI设计师这方面的岗位,工作地点上海,有公司需要的话可以联系我。
关于运维学习、分享、交流,笔者开通了微信公众号【运维猫】,感兴趣的朋友可以关注下,欢迎加入,建立属于我们自己的小圈子,一起学运维知识。
有需要技术交流的小伙伴可以加我微信,期待与大家共同成长,本人微信: