概述

我运行一个具有24个内核的生产Web服务器,其中的工作是CPU和I / O密集型,但主要是CPU.当总CPU负载为~85％或更高时,我的脚本会延迟执行,以保持负载的可管理性.因此,CPU永远不会比我的脚本知道它能够处理更大的压力. 现在,我的服务器在一次最长3小时的时间块内完成最大容量生产.大部分时间工作进展顺利,但在这段时间的中间,CPU系统负载通常会急剧增加.这是由于内核进程“events /

我运行一个具有24个内核的生产Web服务器,其中的工作是cpu和I / O密集型,但主要是cpu.当总cpu 负载为~85％或更高时,我的脚本会延迟执行,以保持负载的可管理性.因此,cpu永远不会比我的脚本知道它能够处理更大的压力. @H_197_16@现在,我的服务器在一次最长3小时的时间块内完成最大容量生产.大部分时间工作进展顺利,但在这段时间的中间,cpu系统负载通常会急剧增加.这是由于内核进程“events / x”,“MIgration / x”和“ksoftirqd / x”,其中“x”是该进程的cpu编号.我已经读过,这表明内核正在努力排队,这会在压倒性的系统负载下发生.但是,正如我所提到的,我的cpu 负载是主要的瓶颈,故意保持在~85％以避免这种问题. cpu的这种内核使用会大大减慢生产速度并且只会延长排队的任务.奇怪的是,在大约30分钟后,系统负载将消失,内核进程减少到零cpu使用率,之后才开始再次占用cpu.在整个这段时间内,输入cpu的工作量没有改变,通常处理得很好.但是,当这些内核进程启动时,它会完全杀死生产.

@H_197_16@以下是其中一个事件中“top -u root”的输出.用户 cpu使用率为49％,因为系统使用率为40％.通常这应该是用户~85％,系统~5％.但是,没有iowait,系统负载平均值为22(24个核心中),这是正常的.

@H_197_16@热门次数 – 13:10:49最多44天,20：29,1位用户,平均负载：22.87,22.73,21.36
任务：总共622,24跑,585睡,0停,13僵尸
cpu(s)：49.4％us,40.3％sy,0.0％ni,10.1％id,0.1％wa,0.0％hi,0.2％si,0.0％st
内存：总计32728060k,使用31045092k,免费1682968k,缓冲353768k
交换：4194300k总计,243136k使用,3951164k免费,19117436k缓存

@H_197_16@PID用户PR NI VIRT RES SHR S％cpu％MEM TIME COMMAND
51 root RT 0 0 0 0 S 11.1 0.0 436：03.06 migration / 12
100 root 20 0 0 0 0 S 9.5 0.0 49：19.45 events / 1
114 root 20 0 0 0 0 S 5.9 0.0 48：14.75 events / 15
3 root RT 0 0 0 0 S 4.3 0.0 517：58.05 migration / 0
112 root 20 0 0 0 0 S 3.6 0.0 42：00.54 events / 13
27 root RT 0 0 0 0 S 2.3 0.0 200：59.58 migration / 6
8149 root 20 0 165m 7732 3928 S 2.3 0.0 0：00.07 exim
15 root RT 0 0 0 0 S 2.0 0.0 450：05.62 migration / 3
39 root RT 0 0 0 0 S 2.0 0.0 178：08.17 migration / 9
113 root 20 0 0 0 0 S 1.6 0.0 44：00.04 events / 14
178 root 20 0 0 0 0 R 1.6 0.0 53：27.57 kacpid
63 root RT 0 0 0 0 S 1.3 0.0 439：11.96 migration / 15
81 root 20 0 0 0 0 S 1.0 0.0 17：14.83 ksoftirqd / 19
104 root 20 0 0 0 0 S 1.0 0.0 44：58.55 events / 5
115 root 20 0 0 0 0 S 1.0 0.0 47：18.46 events / 16
9 root 20 0 0 0 0 S 0.7 0.0 13：56.20 ksoftirqd / 1
25 root 20 0 0 0 0 S 0.7 0.0 12：46.52 ksoftirqd / 5
57 root 20 0 0 0 0 S 0.7 0.0 11：12.62 ksoftirqd / 13
75 root RT 0 0 0 0 S 0.7 0.0 181：00.24 migration / 18
118 root 20 0 0 0 0 S 0.7 0.0 30：13.06 events / 19
10497 root 20 0 77964 6244 4096 S 0.7 0.0 17：40.25 httpd

@H_197_16@当cpu 负载严格控制为可管理时,是否有可能解释这些过程的行为？内存不是问题,因为缓冲区/缓存的使用率绝不会超过30％的系统容量.在搜索网络时,每个人都归咎于压倒性的系统负载,但我的服务器的行为并不表明所使用的资源应该导致这种锁定.

@H_197_16@任何建议,将不胜感激.

@H_197_16@编辑：我已经在答案部分发布了似乎是解决方案的内容.

解决方法

看来内核进程可能在转换到/从交换过程中窃取了cpu时间.服务器的缓存设置在不知情的情况下被重置,将swappiness设置为60.从“sar -W”的输出,挂起似乎与高负载时段一致,在此期间pswpin / s和pswpout / s很大(大于2.00左右,有时高达15.00).将swappiness设置为1之后,我没有遇到来自内核进程的相同挂起,并且sar -W始终显示接近零的值.总而言之,在大量且快速变化的资源需求期间,在高负载和大内存传输期间的积极交换似乎正在使系统陷入困境.