服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 内核进程在高负载期间定期吃CPU
Intereting Posts
puppet：用于尚未安装的软件包中的目录的符号链接 如何在具有相同Publice IP地址的多台Windows Server上承载单个网站 nginx php-fpm一直在下载文件 Windows 2003networking性能落后于租用线路 如何使用scp _MOVE_文件？ 在WAN上运行点对点networking速度testing的好方法是什么？ Linux（Ubuntu 12.04）。 设置OpenSSL和osslsigncode iDRAC 6 Express设置安全的SMTP警报 缓慢的DNS响应 编译PHP7与MySQL错误 Linux虚拟服务器是旧的，还是停滞不前？ a2ensite不显示/ etc / apache2 / sites-available中的所有站点 如何查找文件或文件夹是否在不查看所有文件和文件夹的情况下在NTFS中的另一个文件夹中中断inheritance？ FreeIPMI（ipmi-sensors）不显示HP服务器的PROC / MEM传感器 什么是最好的方式来阻止在Nginx的URL？

内核进程在高负载期间定期吃CPU

我运行了24个内核的生产Web服务器，其中工作是CPU和I / O密集型的，但主要是CPU。 当CPU总负载达到85％或更高时，我的脚本会延迟执行，以保持负载的可pipe理性。 因此，CPU从来没有比我的脚本知道它可以处理更大的压力。

现在，我的服务器一次最多可以容忍3小时以上的容量生产。 大部分时间工作顺利进行，但在此期间，CPU系统负载往往急剧增加。 这是由于内核进程“events / x”，“migration / x”和“ksoftirqd / x”，其中“x”是该进程的CPU编号。 我已经读过，这表明内核正在排队的任务挣扎，这是在压倒性的系统负载下发生的。 但是，正如我所提到的，我的CPU负载是主要瓶颈，为了避免这种问题，故意将其保持在85％左右。 CPU的这种内核使用大大降低了生产速度，只能延长排队的任务。 奇怪的是，大约30分钟后，系统负载将消失，内核进程减less到零CPU使用率，只是稍后再次开始占用CPU。 在这整个过程中，input到CPU的工作量没有变化，通常处理得很好。 但是，当这些内核进程启动时，它完全杀死了生产。

以下是其中一个事件中“top -u root”的输出。 用户CPU使用率为49％，因为系统使用率为40％。 通常这应该是用户〜85％，系统〜5％。 但是，没有iowait，系统的平均负载是24（24核心），这是正常的。

top - 13:10:49 up 44 days, 20:29, 1 user, load average: 22.87, 22.73, 21.36 Tasks: 622 total, 24 running, 585 sleeping, 0 stopped, 13 zombie 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 Mem: 32728060k total, 31045092k used, 1682968k free, 353768k buffers Swap: 4194300k total, 243136k used, 3951164k free, 19117436k cached

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

当CPU负载被严格pipe理为可pipe理时，对于这些进程的行为是否有任何可能的解释？ 内存不是问题，因为缓冲区/高速caching的使用永远不会超过系统容量的30％。 在networkingsearch中，每个人都责怪压倒性的系统负载，但是我的服务器的行为并不表明所使用的资源会导致这种locking。

任何build议，将不胜感激。

编辑：我已经发布似乎是答案部分的解决scheme。

看来，内核进程可能已经偷到了交换中的CPU时间。 服务器的caching设置在我不知情的情况下被重置，将swappiness设置为60.从“sar -W”的输出中，挂断似乎与其中pswpin / s和pswpout / s很大的高负载时段相一致大于2.00左右，有时甚至高达15.00）。 将swappiness设置为1之后，我没有遇到与内核进程相同的挂断，并且sar -W始终显示接近于零的值。 总而言之，看起来在高负载和高内存传输的情况下进行大规模的交换，在大规模和快速变化的资源需求的时代陷入困境。

我跟踪了这里报告的迁移内核进程的问题。 看来3.6.11之前的linux内核会受到影响。 链接显示迁移过程占用大量CPU时间的类似症状。 如果可能，您可能需要升级内核以查看问题是否仍然存在。

migration是处理从一个CPU移动到另一个CPU的内核进程。

所以，出于某种原因，您的Linux调度程序决定进程需要移动到另一个CPU，并且迁移过程会消耗CPU时间。

你可以尝试固定进程到特定的CPU，或者尝试不同的调度程序与你的内核。 也许其他一些调度程序并不急于将进程迁移到其他CPU。