为什么kswapd使用100%的CPU,没有交换空间,有足够的caching可用于收割?

Firefox使用了大量的内存,并且使用大多数CPU使用kswapd / kworker几乎停止了。 Linux 4.5.7(Fedora 24)没有交换空间,而vm.swappiness = 0。

我不明白的是,有近1.5GB的buff / cache,为什么Linux没有收获Firefox / plugin-container的caching? 什么是kswapd在做什么?

 top - 13:17:15 up 2:47, 4 users, load average: 9.78, 5.38, 2.35 Tasks: 197 total, 4 running, 193 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.8 us, 47.0 sy, 0.0 ni, 10.0 id, 36.9 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 3922860 total, 105508 free, 2353620 used, 1463732 buff/cache KiB Swap: 0 total, 0 free, 0 used. 6828 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 49 root 20 0 0 0 0 R 100.0 0.0 2:35.25 kswapd0 6395 kevin 20 0 1152968 371132 4292 R 31.7 9.5 3:16.59 plugin-containe 3449 root 20 0 0 0 0 S 26.3 0.0 0:24.49 kworker/u16:3 5885 root 20 0 0 0 0 S 23.8 0.0 0:34.12 kworker/u16:2 4246 root 20 0 0 0 0 S 22.9 0.0 0:42.11 kworker/u16:4 6236 root 20 0 0 0 0 R 19.0 0.0 0:38.84 kworker/u16:1 4700 root 20 0 0 0 0 S 17.8 0.0 0:40.57 kworker/u16:5 3473 kevin 20 0 1662688 402008 460 D 8.3 10.2 7:36.45 thunderbird 1846 elastic+ 20 0 4238960 401324 124 S 5.7 10.2 3:05.58 java 6107 kevin 20 0 2133616 602096 20920 S 5.1 15.3 4:03.21 firefox... 

我不认为我最近做了什么I / O写操作,所以我不希望任何脏页面刷新到磁盘(SSD),虽然等待是37%,这有点令人惊讶。 我抓住了大约30秒的topbuff/cache没有太大的变化,所以我不认为它实际上是冲洗任何页面到磁盘(虽然然后我不明白为什么等待%高):

 $ grep -e "top -" -e "buff/cache" top.txt top - 13:17:11 up 2:47, 4 users, load average: 9.41, 5.23, 2.29 KiB Mem : 3922860 total, 103468 free, 2353456 used, 1465936 buff/cache top - 13:17:15 up 2:47, 4 users, load average: 9.78, 5.38, 2.35 KiB Mem : 3922860 total, 105508 free, 2353620 used, 1463732 buff/cache top - 13:17:21 up 2:47, 4 users, load average: 10.44, 5.59, 2.43 KiB Mem : 3922860 total, 108700 free, 2354532 used, 1459628 buff/cache top - 13:17:24 up 2:47, 4 users, load average: 10.72, 5.73, 2.50 KiB Mem : 3922860 total, 107004 free, 2355112 used, 1460744 buff/cache top - 13:17:43 up 2:47, 4 users, load average: 12.64, 6.39, 2.77 KiB Mem : 3922860 total, 108264 free, 2352820 used, 1461776 buff/cache top - 13:17:46 up 2:47, 4 users, load average: 12.27, 6.42, 2.79 KiB Mem : 3922860 total, 108580 free, 2352584 used, 1461696 buff/cache 

杀死firefoxplugin-container使系统恢复正常。 我宁愿caching被完全刷新,以提供更多的空间,或者至lessOOM杀手在这种情况下运行,而不是必须做Ctrl+Alt+F2因为KDE没有响应,等待login的永恒提示,最后做一个小pkill

这是一个超级用户的问题,而不是serverfault,但我自己在Fedora 24上。

它是由ffmpeg-libs,VDPAU和我的GPU /内核引起的。 对我来说,我禁用了VLC中的VDPAU来“修复”它。

它在/proc/meminfo和受影响的进程中显示为一个不断增加的Shmem大小,如果您的pmap显示数百个“renderD128”的映射且不断增加。

它的实现错误比可能更多 – 在video处理应用程序中禁用VDPAU输出。