软件性能测试(连载7)

2020-02-19 15:31:09 浏览数 (1)

6)CPU状态转换

CPU状态转换如图3-18所示。

图3-18 CPU状态转换图

7)软中断与硬中断

假设现在一家公司就有一名客服人员,这个客服人员就有一台座机,这种情况下用户碰到问题只能打电话给这个客服人员,如果有多个用户同时打入只能凭运气,先打通电话的人得到回答,其他人只能依次等待。显然这种处理机制是非常低效的,小公司可能还可以,大一点的公司就不行了。于是现在共有4-5位客服人员,建立总分机架构,1位负责总机(也可以交给语音提示来操作),负责把问题分给4个分机,让4个分机人员来处理具体的问题,这样一来效率就明显提高了。如果客户来电,总机负责人接电话分给分机人员(或通过语音提示用户拨打分机号)叫做硬中断,而分机负责人处理具体问题叫做软中断。Linux的CPU正是采用硬中断与软中断结合的方式来处理问题的。比如现在网卡告诉CPU,有一批数据要从网络中过来,希望系统做好接收准备,CPU手头的工作被打断(中断),将网络上的数据存储在寄存器中,然后呼起一个进程来处理后续操作,就回头处理刚才中断之前的工作了。被呼起的进程可以在后台“慢慢地”地把寄存器中的数据按照规定格式写入数据库中。这里CPU处理的过程就为硬中断过程,而进程把数据写入数据库中过程为软中断过程。具体如图3-19所示。

图3-19 软中断与硬中断

硬中断可以用命令cat /proc/interrupts来查看,而软中断可以用cat /proc/softirqs来查看。由于硬中断比软中断过程短得多,所以作为性能监控往往需要监控软中断。

#cat /proc/softirqs

CPU0 CPU1

HI: 0 0

TIMER: 811613 1972736

NET_TX: 49 7

NET_RX: 1136736 1506885

BLOCK: 0 0

IRQ_POLL: 0 0

TASKLET: 304787 3691

SCHED: 689718 1897539

HRTIMER: 0 0

RCU: 1330771 1354737

其中。

•TIMER。

定时产生的软中断。

•NET_RX。

网络接收产生的软中断。

•NET_TX。

网络发送产生的软中断。

•SCHED。

内核调度产生的软中断。

•RCU。

RCU产生的软中断。

扩展阅读:RCU[32]RCU(Read-Copy Update),顾名思义就是读/拷贝/修改。对于被RCU保护的共享数据结构,不需要获得任何锁就可以访问它,但写者在访问它时首先拷贝一个副本,然后对副本进行修改,最后使用一个回调(callback)机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作

另外也经常使用ps aux | grep softirq命令来查看产生中断进程。

#ps aux | grep softirq

root 7 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/0]

root 16 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/1]

注意:有[]为内核进程,可见软中断进程属于内核进程。

在top命令中也可以看到软中断进程。

#top

top - 10:50:58 up 1 days, 22:10, 1 user, load average: 0.00, 0.00, 0.00

Tasks: 122 total, 1 running, 71 sleeping, 0 stopped, 0 zombie

%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 3.3 si, 0.0 st

%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st

...

PIDUSER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND

7 root 20 0 0 0 0 S 0.3 0.0 0:01.64 ksoftirqd/0

16 root 20 0 0 0 0 S 0.3 0.0 0:01.97 ksoftirqd/1

2663root 20 0 923480 28292 13996S 0.3 0.3 4:58.66 docker-containe

3699root 20 0 0 0 0 I 0.3 0.0 0:00.13 kworker/u4:0

3708root 20 0 44572 4176 3512 R 0.3 0.1 0:00.07 top

1root 20 0 225384 9136 6724 S 0.0 0.1 0:23.25 systemd

2root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd

除了可以使用cat /proc/softirqs查看当前软中断状态,在实际工作中也常常使用watch -d cat /proc/softirqs来动态显示实时软中断状态。

案例3-12:小包问题

#watch -d cat /proc/softirqs

CPU0 CPU1

HI: 0 0

TIMER: 1083906 2368646

NET_TX: 53 9

NET_RX: 1550643 1916776

BLOCK: 0 0

IRQ_POLL:0 0

TASKLET: 333637 3930

SCHED: 963675 2293171

HRTIMER: 0 0

RCU: 1542111 1590625

上面结果中可以看出,网络发送产生了大量软中断。然后通过sar -n DEV 1命令来进一步分析。

#sar -n DEV 1

15:03:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil

15:03:47eth0 35645.00 6304.00 857.43 358.11 0.00 0.00 0.00 0.01

15:03:47docker0 6302.00 12604.00 270.79 664.66 0.00 0.00 0.00 0.00

15:03:47 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

15:03:47 veth9f6bbcd6302.00 12604.00 356.95 664.66 0.00 0.00 0.00 0.05

在这里。

•15:03:46。

表示报告的时间。

•IFACE。

表示网卡名。

•rxpck/s和txpck/s。

分别表示每秒接收、发送的网络帧数,也就是PPS。

•rxkB/s和txkB/s

分别表示每秒接收、发送的千字节数,也就是BPS。

在上面结果中,857(txpck/s)×1024/35645(rxpck/s)= 24字节,说明平均每个网络帧只有24字节,这显然是很小的网络帧,也就是通常所说的小包问题。确定是小包是问题后,就可以使用类似tcpdump工具进行进一步排查了。

8)CPU使用率

CPU使用率=1-CPU空闲时间/CPU总时间。

平均CPU使用率=1- (CPU空闲时间New- CPU空闲时间Old)/ (CPU总时间New- CPU总时间Old)

top命令显示了系统总体的CPU和内存使用情况,以及各个进程的资源使用情况。而ps命令则只显示了每个进程的资源使用情况。

9)CPU节拍率

CPU节拍率指每秒钟CPU切换的次数,单位为HZ。一般为:100HZ、250HZ、1000HZ,如果CPU节拍率为250HZ,表示:每秒钟触发250次切换,即每次切换持续1/250s。CPU节拍率可以通过grep 'CONFIG_HZ='/boot/config-$(uname -r)命令得之。

#grep 'CONFIG_HZ=' /boot/config-$(uname -r)

CONFIG_HZ=250

如图3-20所示,当前Memory中有“0”“1”“2”“3”“4”5个请求等待CPU处理。在当前时间段内CPU处理第“2” 号请求,过了1/250s(假设CPU节拍率为250),处理第“3”号请求,然后依次循环处理“4”“0”“1”…号请求。

图3-20 CPU节拍率

0 人点赞