私のコンピュータには、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