现在,我的服务器在一次最长3小时的时间块内完成最大容量生产.大部分时间工作进展顺利,但在这段时间的中间,cpu系统负载通常会急剧增加.这是由于内核进程“events / x”,“migration / x”和“ksoftirqd / x”,其中“x”是该进程的cpu编号.我已经读过,这表明内核正在努力排队,这会在压倒性的系统负载下发生.但是,正如我所提到的,我的cpu负载是主要的瓶颈,故意保持在~85%以避免这种问题. cpu的这种内核使用会大大减慢生产速度并且只会延长排队的任务.奇怪的是,在大约30分钟后,系统负载将消失,内核进程减少到零cpu使用率,之后才开始再次占用cpu.在整个这段时间内,输入cpu的工作量没有改变,通常处理得很好.但是,当这些内核进程启动时,它会完全杀死生产.
以下是其中一个事件中“top -u root”的输出.用户cpu使用率为49%,因为系统使用率为40%.通常这应该是用户~85%,系统~5%.但是,没有iowait,系统负载平均值为22(24个核心中),这是正常的.
热门次数 – 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缓存
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
当cpu负载严格控制为可管理时,是否有可能解释这些过程的行为?内存不是问题,因为缓冲区/缓存的使用率绝不会超过30%的系统容量.在搜索网络时,每个人都归咎于压倒性的系统负载,但我的服务器的行为并不表明所使用的资源应该导致这种锁定.
任何建议,将不胜感激.
编辑:我已经在答案部分发布了似乎是解决方案的内容.
解决方法 看来内核进程可能在转换到/从交换过程中窃取了cpu时间.服务器的缓存设置在不知情的情况下被重置,将swappiness设置为60.从“sar -W”的输出,挂起似乎与高负载时段一致,在此期间pswpin / s和pswpout / s很大(大于2.00左右,有时高达15.00).将swappiness设置为1之后,我没有遇到来自内核进程的相同挂起,并且sar -W始终显示接近零的值.总而言之,在大量且快速变化的资源需求期间,在高负载和大内存传输期间的积极交换似乎正在使系统陷入困境. 总结以上是内存溢出为你收集整理的linux – 内核进程在高负载期间定期占用CPU全部内容,希望文章能够帮你解决linux – 内核进程在高负载期间定期占用CPU所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)