web-dev-qa-db-ja.com

kswapdが100％CPUを使用するのに、スワップスペースがなく、リーピングに利用できるキャッシュが十分あるのはなぜですか

Firefoxは大量のメモリを使用し、ほとんどのCPUを使用するkswapd/kworkerでマシンがほぼ停止状態になりました。スワップスペースはなく、Linux 4.5.7（Fedora 24）ではvm.swappiness = 0です。

私が理解していないのは、1.5GB近くのバフ/キャッシュがあるのに、LinuxがFirefox/plugin-container用にそのキャッシュを取得しなかったのはなぜですか？ 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秒分のtopを取得しましたが、buff/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

firefoxとplugin-containerを強制終了すると、システムが正常に戻りました。キャッシュを完全にフラッシュしてヘッドルームを増やすか、少なくとも、KDEが応答せず、ログインを永遠に待つため、Ctrl+Alt+F2を実行する代わりに、この状態でOOMキラーを実行することをお勧めします。プロンプトを出し、最後にpkillを実行します。

linuxcpu-usageswap
4
averageradical

これはserverfaultではなくスーパーユーザーの質問ですが、私自身もFedora 24でこの問題を抱えていました。

その原因は、ffmpeg-libs、VDPAU、および私のGPU /カーネルです。私にとっては、VLCでVDPAUを無効にして「修正」しました。

/proc/meminfoではShmemのサイズが増え続けており、pmapの場合は影響を受けるプロセスとして表示され、「renderD128」の何百ものマッピングが表示され、増え続けています。

それはおそらく実装上のバグであるはずです-ビデオ処理アプリケーションでVDPAU出力を無効にしてください。

0
Matthew Ife