Linuxキャッシュ/スワップ率を微調整する方法は?

Linuxキャッシュ/スワップ率を微調整する方法は?

私のコンピュータには、GUIが死ぬまでほとんど利用できなくなり、非常に混乱する問題がありました。

私は分析の結果、これがキャッシュ/バッファのためにあまりにも多くのスワップが発生したために発生したと結論付けました。これらの設定を細かく調整する方法はありますか?

ユースケース:SSDではなくハードドライブから大量のデータを読み書きするだけです。ddまたはf3read/を使用するとしますf3write。約1分後にキャッシュまたはバッファが大きすぎると、Linuxは一括交換を開始します。

このatopコードスニペットでは、PAG行でこれを見ることができます。

MEM |  tot    15.5G |  free    3.5G  | cache   7.8G  |  buff   96.1M |  slab  394.5M |  vmbal   0.0M  | hptot   0.0M  |
SWP |  tot     1.0G |  free  634.7M  |               |               |               |  vmcom   8.5G  | vmlim   8.8G  |
PAG |  scan  156637 |  steal 156616  | stall      0  |               |               |  swin       0  | swout  11814  |
PSI |  cs     0/0/2 |  ms     5/2/2  | mf     5/2/1  |  is  50/24/15 |  if  50/24/15 |                |               |
DSK |           sdb |  busy     56%  | read      61  |  write   1312 |  MBr/s    0.0 |  MBw/s  147.8  | avio 3.95 ms  |
DSK |           sda |  busy     24%  | read     100  |  write  11803 |  MBr/s    0.2 |  MBw/s    4.6  | avio 0.20 ms  |

このフィールドの意味を完全に理解していません。しかし、ラップトップでも同じように試しました。SWOUT統計がはるかに低く、システムが影響を受けないことを除いて、すべてが似ています。

どちらのシステムにもUbuntu 19.10カーネル5.3.0-19-genericがあります。スワップはSSDにあります。 SSDデータによると、atop使用量は20%〜50%で、主にスワッピングによって発生します。

60から10に設定しようとしましたが、/proc/sys/vm/swappiness役に立ちませんでした。 100から50に設定しましたが、vfs_cache_pressureそれも役に立ちませんでした。

その理由が他の場所にある可能性がありますか? SATAの問題がありましたが、今は解決する必要があります。一度(Intelで)これが起こりましたが、GPU HANG交換の問題によって発生したようです...

この問題を見始めたとき(徹底的に分析する前に)、常に問題が発生したため、スワップ(以前はありませんでした)を追加しましたkswapd。スワップを追加すると、少なくともkswapdがCPUの100%を占めるのを防ぎます。

どんなアイデアがありますか?

答え1

解決策が見つかりました。カーネル4を使用してください。

Ubuntu 19.10 Eoanでは、これはリポジトリで利用可能な唯一の4.xカーネルであるlinux-image-4.15.0-1050-oemカーネルをインストールすることを意味します。 19.4より前のカーネルを試してみましたが、Ubuntu 19.10では動作しません。

実際の原因を調べて、見つかった場合はここに解決策を投稿します。

それまでは、これが可能な方向になると思います。 https://bugs.freedesktop.org/show_bug.cgi?id=111790

関連情報