我知道flush进程是内核的垃圾收集器，但在我的情况下，在两台服务器上，这个进程实际上是CPU处理器。 在大多数情况下，它使用80-100％的CPU。
2898 root 20 0 0 0 0 R 78 0.0 2900:22 flush-0:21 什么可以导致这一点。 我想过内存已损坏，但一次在两台服务器上？ 我认为内核升级后就开始发生了。 也许有一些已知的错误？
编辑：
更新的信息。 这是Gentoo Linux 64位，内核版本是2.6.39-gentoo-r2。 它有8 GB的RAM。 没有太多的IO活动。
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 5.01 87.19 5.55 166452685 10596484 sdb 5.01 87.30 5.55 166662767 10596484 md0 10.05 160.74 2.75 306883505 5258392 md1 3.61 13.74 2.10 26229593 4006684
奇怪的是，sda / sdb上的IO活动，这些是交换分区，即closures。
我们只使用uwsgi程序和一些从crontab运行的Python脚本。
iostat -x 5
Linux 2.6.39-gentoo-r2 (python-1) 07/27/11 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 44.98 0.00 3.73 0.81 0.00 50.48 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 1.37 0.70 4.35 0.67 87.16 5.55 37.00 0.08 15.16 15.61 12.21 3.07 1.54 sdb 1.37 0.70 4.35 0.67 87.27 5.55 36.99 0.07 14.84 15.22 12.35 3.11 1.56 md0 0.00 0.00 9.36 0.69 160.67 2.76 32.51 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 3.11 0.50 13.76 2.09 8.79 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 68.24 0.00 25.01 0.30 0.00 6.45 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.20 1.20 0.80 4.80 4.00 8.80 0.01 7.10 7.50 6.50 7.10 1.42 sdb 0.00 0.20 1.00 0.80 4.80 4.00 9.78 0.01 7.00 6.00 8.25 7.00 1.26 md0 0.00 0.00 0.00 0.60 0.00 2.40 8.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 2.00 0.00 8.80 0.00 8.80 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 68.24 0.00 21.13 1.18 0.00 9.45 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 1.20 0.00 6.40 0.00 10.67 0.01 6.50 6.50 0.00 6.50 0.78 sdb 0.00 0.00 1.40 0.00 7.20 0.00 10.29 0.02 11.43 11.43 0.00 11.43 1.60 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 2.60 0.00 13.60 0.00 10.46 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 60.73 0.00 22.34 2.75 0.00 14.18 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 5.40 0.00 22.40 0.00 8.30 0.08 14.22 14.22 0.00 6.04 3.26 sdb 0.20 0.00 3.80 0.00 36.80 0.00 19.37 0.03 7.74 7.74 0.00 7.74 2.94 md0 0.00 0.00 7.00 0.00 48.80 0.00 13.94 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 2.40 0.00 10.40 0.00 8.67 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 74.22 0.00 20.08 1.25 0.00 4.45 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.20 2.20 10.80 0.60 92.00 11.20 18.11 0.07 5.81 5.78 6.33 5.81 6.62 sdb 0.60 2.20 11.60 0.60 144.80 11.20 25.57 0.08 6.92 6.83 8.67 6.25 7.62 md0 0.00 0.00 22.00 2.40 226.40 9.60 19.34 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 1.20 0.00 10.40 0.00 17.33 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 69.17 0.00 21.25 0.85 0.00 8.72 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.60 0.00 2.40 0.00 8.00 0.00 6.00 6.00 0.00 6.00 0.36 sdb 0.00 0.00 0.80 0.00 7.20 0.00 18.00 0.01 9.75 9.75 0.00 9.75 0.78 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 1.40 0.00 9.60 0.00 13.71 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 56.99 0.00 22.66 3.63 0.00 16.73 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 1.60 1.20 8.00 4.80 9.14 0.02 8.00 10.62 4.50 7.21 2.02 sdb 0.00 0.00 1.40 1.20 7.20 4.80 9.23 0.02 8.38 10.71 5.67 8.15 2.12 md0 0.00 0.00 0.40 0.80 1.60 3.20 8.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 2.60 0.00 13.60 0.00 10.46 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 68.65 0.00 25.95 1.55 0.00 3.85 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.40 45.80 43.20 19.40 445.60 260.80 22.57 0.48 7.71 9.05 4.73 4.67 29.26 sdb 1.00 45.80 48.00 19.40 607.20 260.80 25.76 0.56 8.26 9.70 4.70 4.06 27.36 md0 0.00 0.00 102.40 64.40 1020.00 257.60 15.32 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 6.80 0.00 33.60 0.00 9.88 0.00 0.00 0.00 0.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 67.86 0.00 22.76 2.03 0.00 7.35 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 8.80 1.00 74.20 0.80 590.40 7.20 15.94 0.26 3.46 3.44 4.50 3.07 23.06 sdb 2.20 1.00 77.80 0.80 552.00 7.20 14.23 0.31 3.94 3.92 6.00 3.30 25.96 md0 0.00 0.00 115.20 1.40 907.20 5.60 15.66 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 48.00 0.00 234.40 0.00 9.77 0.00 0.00 0.00 0.00 0.00 0.00
flush不是“内核中的垃圾回收”。 我不知道你在哪里阅读，但C没有垃圾收集器。 没有自动内存pipe理。 C程序员必须pipe理自己的内存分配。 无论如何…
flush是虚拟内存子系统用来将脏页写出到磁盘的过程。 这在EL内核中被称为pdflush或bdflush 。
当您执行任何（非直接）IO时，您访问的文件将进入页面caching。 如果您从磁盘读取文本文件，则该文本文件现在存在于磁盘和caching中。 如果您进行了一些更改并保存该文件，则文本编辑器实际执行的write()系统调用将完成对内存中文件的副本的操作。 这样，系统调用会很快返回，您的文本编辑器可以恢复接受您的input，而不是在将数据写入相对较慢的硬盘时暂停。 修改后的文本文件占用的内存页面现在称为“脏页面”。 内核担心后来将实际的块写入磁盘，这被称为“同步”或“刷新脏页”。
你会期望看到一个刷新过程有时会得到高CPU使用率，因为这个过程将IO执行到磁盘，并且可能将大部分时间花费在Iowait上。
没有什么可担心的。 你的系统和其他Linux系统一样。