Redhat Bugzillaに投稿されたものと同じです。kcompacd0はCPUを100%使用します。、締め切りはですINSUFFICIENT_DATA
。
また
そこにあるソリューションが私には効果がなかったので、もう一度開きます。
私の状況は次のとおりです。
- Ubuntu21.10ホストとWindows10VMware Workstation 16 v を使用するエンタープライズクライアント16.2.0ビルド-18760230
- 私は派手な作業や負荷のかかる作業をしていませんでしたが、Windows 10(軽負荷)を定期的に使用してから1日で状況が変になり始めました。
- プロセスは1つのコアで100%CPUを使用し、8つのコアで100%CPUを
kcompactd0
継続的に使用します。vmware-vmx
- これが起こると、通常は数分間続きます。その後、1〜2分後に再起動します。
- 「kcompactd0はdrop_cachesからのみ消えます。100%に達すると、vmwareゲストは完全に応答しません(windows 10 ltsc vm)。」だから私はdrop_cachesを一度だけ試してみて、動作を確認しました。
アップストリームが要求したように、追加情報は次のとおりです。
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never
/sys/kernel/mm/transparent_hugepage/enabled:always [madvise] never
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:1
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1
$ cat /proc/90/stack | wc
0 0 0
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled
$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise madvise [never]
/sys/kernel/mm/transparent_hugepage/enabled:always madvise [never]
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:0
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1
デフォルトでは、ソリューションのソースは次のとおりです。Fedoraエラーレポート「khugpagedがCPUを100%占めています」。バグは修正されておらず、「ソリューション」は2013年のFedora 17に関するものでした。
最後の3つ、おそらく4-5個のFedoraカーネルバージョンでは、この問題は再び発生しませんでした。
しかし今、そのようなことが再び起こりました。
答え1
Ubuntu 20.04の私の解決策は次のとおりです。
- 仮想マシンのシャットダウン
- テキストエディタを使用してVMの<vm_name> .vmxファイルを開きます。
- vmx ファイルの末尾に以下を追加します。
# Fix problem where vmware battles with kcompactd0.
vm.compaction_proactiveness=0
- ファイルを保存し、VMを再起動します。
[アップデート 2022-03-06]: VMware Workstation Pro 16.2.1 にアップグレードした場合は、テストする前に必ず仮想マシンを 16.2 にアップグレードし、マシンを再起動してください。アップグレード後に再起動しなかったが、再起動まで問題が続いた。
[更新 2022-11-28]: 「アクセラレーション 3D グラフィックス」が有効になっていることを確認し、必要でない場合は無効にします。これがこの問題の原因である可能性があります。
答え2
これは実際にIOMMUの問題であり、回避策はカーネルコマンドラインで有効にすることです。ファームウェアでVT-d(Intel IOMMUカーネルドライバ)を有効にするだけでは不十分です。 Compaction_proactivenessとswappinessにパッチを適用すると、根本的な原因を解決せずに動作のみが制限されます。
私はこの問題に直接遭遇しました(Ubuntu 22.04ホスト、カーネルバージョン5.15.0、VMware Player 16.2.4、Windows 10ゲスト)。これは、ゲストコンピュータでFirefox、データベースアプリケーション、またはその両方で複数のタブが開いている場合に特に当てはまります。
設定が何も影響しないことは注目に値しますvm.compaction_proactiveness=0
。設定はvm.swappiness=10
少し役に立ちましたが、問題はまだ残っています。
VT-xとVT-dはホストファームウェアで有効になっていますが、少なくともカーネルバージョン5.15.0-46-defaultでは、カーネルがデフォルトで無効になっているintel_iommuにコンパイルされることがわかりました。したがって、
cat /boot/config* | grep INTEL_IOMMU
(他の行の中から)返します(octothorpeは2行目をコメントアウトしました)。
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
解決策カーネルのコマンドラインに次の文字列を追加します。これにより、 intel_iommu が有効になり、ゲスト停止の問題が解決され、kcompactd0
少なくとも現在、CPU コアが 100% に固定されるのを防ぎます。
intel_iommu=on
だから、GRUBの場合、/etc/default/grub
上記の文字列をに追加するように編集しGRUB_CMDLINE_LINUX_DEFAULT
、例えば、
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"
ファイルを保存して閉じたら、次を実行します。
# update-grub
適用するには再起動してください。
~のためシステム起動、(a)上記の文字列を別の行に追加する/etc/kernel/cmdline
か、(b)開始エントリ.confファイルに次のキーを追加します/loader/entries
。
options intel_iommu=on
ファイルを保存して閉じてから再起動すると適用されます。
編集する
この質問は部分的にIOMMUの質問ですが、いくつかの追加情報が表示されました。
- 上記のようにIOMMUを設定すると、多くの役に立ちますが、決定的ではありません。問題が再発生します。
- もちろん、この質問は、Windowsゲストのメモリ管理とLinuxホストのメモリ管理との相互作用に関連しています。特に、アプリケーションのSuperfetch機能を無効にする(実行しない)ようにWindowsゲストを設定すると、多くの場合に役立ちます。 Superfetchは実行時に必要と思われるアイテムを事前ロードするため、後でより速くロードされます。これはすべてRAMに入り、仮想マシンのRAM消費量を増やし、回復と圧縮のためのスペースを節約します。この機能をオフにすると、オンデマンドロードとアンロードが可能です。
- また、仮想マシンの設定で VMware VM の RAM 構成を減らすことも多くの役に立ちます。最初はこれが直感にずれているように見えるかもしれませんが、VMware Playerは最初からホストシステムからこれらのRAMをすべて持っているので、ホストに再割り当てと圧縮のためのスペースが少なくなります。 16 GB(16384 MB)RAMを搭載したシステムで、VM RAMを〜12 GBから8192 MBに減らすことで、実際に問題が解決しました。
- それでも問題は数時間使用後に発生する可能性が高く、つまり、その日遅く。凍結期間ははるかに短いですが(分ではなく秒)、一度起動すると凍結したままになります。おそらく削除する必要があるのはホストなのかゲストなのかわかりません。 VMware Player とその RAM が先制実行されるように再起動するのではなく、ゲストを完全にシャットダウンすると効果的なリセットになります。時にはホストの再起動も必要です。
- Firefoxは、少なくともデフォルト設定では多くのRAMを必要とする場合もあれば、あきらめない場合もあります。これは詳細設定である程度構成できます。
ずっと見守ってください。
答え3
echo 0 > /proc/sys/vm/compaction_proactiveness
または
sudo sh -c 'echo 0 > /proc/sys/vm/compaction_proactiveness'
源泉:https://gist.github.com/2E0PGS/2560d054819843d1e6da76ae57378989
答え4
Debian Linux の VMware Workstation 17 および 17.5 で同じ問題が発生しました。
この問題が設定の使用に関連しているかどうか疑問に思います。すべての仮想マシンメモリを予約されたホストRAMにマウントする、これはVMware GUIのデフォルト設定にあります。おそらく、同じ設定ウィンドウで「予約済みメモリ」設定が高すぎると関連している可能性があります。
具体的には、次のようにこれらの設定を変更しました。一部の仮想マシンのメモリ交換を許可、この問題が解決することを願っています。