kswapd0は多くのCPUを使用しています


45

kswapd0がCPUの99.9%を使用していることを示しています。問題は今日ゲームで発生し、6分後に初めて消えてから約20分間続いています。これはどのように修正可能であり、これは何が原因ですか?


これはUbuntu 14.04でも起こります。
eri0o

これは18.04でも起こっています。詳細はこちら:askubuntu.com/questions/1118932/...
ユブラージJaiswal

回答:


48

プロセスkswapd0は、仮想メモリを管理するプロセスです。マシンに、HDD / SSDにRAM、SWAP、EXT4が必要です。ext4はすべてが保存される場所であり、RAMよりも常にアクセスが遅くなります。RAMは、プログラムが情報にすばやくアクセスするための中間的な実行スペースのようなものです。ほとんどのコンピューターには少なくとも4GBのRAMがあり、通常の状態では十分です。ただし、ゲームをプレイするときは、RAMスペースが不足する可能性があります。これがSWAPの出番です。

SWAPは、EXT4の隣のHDD / SSDにある偽のRAMです。EXT4よりもアクセスは高速ですが、実際のRAMよりもはるかに低速です。メモリが不足すると、kswapd0は使用していない/使用していないプログラムを他のプログラムと同じようにSWAPに移動します。これにより、これらのプロセスで極端な遅延が発生します。ゲームに5GBのRAMが必要な場合、最低でも1GBがスワップになります。つまり、その情報にアクセスしようとすると、情報を取得するまでにさらに長く待たなければなりません。

このプロセス全体により、CPUとCPUが極端に使用され、SWAPとRAMの間で情報が移動され、情報の要求がすべて同時に処理されます。この問題を解決するには?

  1. RAMが完全に使い果たされた場合にのみ、SWAPにデータを移動するようkswapd0に指示します。これは、SWAPの問題を解決するための最も効果的な方法です。走る

    echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf

    ここ0で、100SWAPを使用すべき残りの割合(RAMが0%になると、SWAPはデータの取り込みを開始します)。また、geditやnanoなどを使用して毎回このコマンドを最後に追加する代わりに、お好みに合わせて/etc/sysctl.confを編集することもできます。ただし、このファイルはルート所有です。再起動すると設定が完了しました!

  2. ハイメモリプログラムを実行中に、他のプロセスによるRAMの消費を減らすか、他のプログラムを閉じます。これが、ほとんどのゲームがプレイする前に他のすべてのウィンドウを閉じるように指示するか、インストールが同じことをする理由です。ファイル同期サービスのようなものは、多くのメモリを消費する傾向があります。
  3. RAMを追加購入します。RAMのインストールは思ったほど難しくありません。小さなコンパートメント(ラップトップを使用している場合)の1つまたは2つのネジと簡単なクリック。正しい種類を購入していることを確認してください!
  4. RAMの場合と同様に、CPUのプロセスを下げます。これにより、RAMからSWAPへのバーストがよりスムーズになります。

それがあなたにできる最高のことです。他の人はスワップを完全に無効にすると言うかもしれませんが、それは危険であり、私はそれをお勧めしません。これにより、メモリリークや実行中のアプリケーションが多すぎる場合、システム全体がフリーズする可能性があります。SWAPはRAMのフェイルセーフであることを認識してください。RAMほど高速でも効率的でもありませんが、Windowのページファイルよりも優れています!(同じ目的を達成します)

編集:SWAPの詳細については、こちらをご覧ください


何が問題を解決したのかを正確に思い出すことはできませんが、よく説明されたよく書かれた答えに感謝します。
キャスパー14

あなたの答えによると、使用するスワップが少なくなるようにプロセスを終了します。これでプロセスkwapd0は終了しました。ありがとう。
mtoloo

28

kswapd0は1つのCPUの99.9%で実行されますが、実際にはまったくスワップしていません

私にとっては、VMware vmで実行されているカーネル3.19.0-50-generic(およびそれ以前)のUbuntu 14.04で時々発生します。私はそれが何を見せたのか見当もつかないが、それはアイドル時間中に来る。

top ショー:

# top
top - 09:49:35 up 5 days, 18:35,  1 user,  load average: 1.00, 1.00, 0.99
Tasks: 219 total,   2 running, 217 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 25.0 sy,  0.0 ni, 74.7 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:   3028784 total,  1874468 used,  1154316 free,  1010276 buffers
KiB Swap: 15624188 total,     3032 used, 15621156 free.   234928 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    52 root      20   0       0      0      0 R  99.7  0.0 122:15.21 kswapd0
     3 root      20   0       0      0      0 S   0.3  0.0   0:29.86 ksoftirqd/0
     7 root      20   0       0      0      0 S   0.3  0.0   9:49.47 rcu_sched

一時的な解決策

再起動により問題が解決しました-一時的に。

私のシステムで同じ設定が行われているサーバーフォールト(スワップが使用されている場合、kswapdはしばしば100%のCPUを使用します)に関する回答に従います:

# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

実際の解決策は# echo 1 > /proc/sys/vm/drop_caches次のとおりです。

# cat /proc/sys/vm/drop_caches
0
# echo 1 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
1

今は大丈夫です:

# top
top - 10:08:58 up 5 days, 18:55,  1 user,  load average: 0.72, 0.95, 0.98
Tasks: 220 total,   1 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   3028784 total,   681704 used,  2347080 free,     2916 buffers
KiB Swap: 15624188 total,     3032 used, 15621156 free.    81924 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
     9 root      20   0       0      0      0 S   0.3  0.0  14:10.40 rcuos/0
     1 root      20   0   45652   8124   2888 S   0.0  0.3   1:54.98 init

恒久的な解決策(見つかる)?

しかし、実際の理由はまだわかっておらず、ネット上で適切な説明をしていないので、これは永続的な解決策ではありません。実際、選択された答えは永続的な解決策かもしれません。(sysctlを有効にするための)再起動が常に可能であるとは限らないため、将来の参照用にこれを追加したかっただけです。

他のソリューションは、に設定したTHPである可能性がありますいずれかmadviceまたはnever(参照poigeの彼へのコメントの答えを私は変更するにはどうすればよい「/ SYS /カーネル/ MM / transparent_hugepage /有効」との参照MongoDBのマニュアルを無効に透明な巨大ページ(THP)

cronジョブ

「永続的な」ソリューションとして、次のバッチをcronジョブとして設定しました。

#!/bin/bash


## run as cron, thus no $PATH, thus need to define all absolute paths
top=/usr/bin/top
grep=/bin/grep


top=$($top -bn1 -o \%CPU -u0 | $grep -m2 -E "%CPU|kswapd0")

IFS='
'
set -f

i=0

for line in $top
do
        #echo $i $line

        if ! (( i++ ))
        then
                pos=${line%%%CPU*}
                pos=${#pos}
                #echo $pos
        else
                cpu=${line:(($pos-1)):3}
                cpu=${cpu// /}
                #echo $cpu
        fi

done

[[ -n $cpu ]] && \
(( $cpu >= 90 )) \
&& echo 1 > /proc/sys/vm/drop_caches \
&& echo "$$ $0: cache dropped (kswapd0 %CPU=$cpu)" >&2 \
&& exit 1

exit 0

で呼び出される

# m h  dom mon dow   command
  * *  *   *   *     /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1


非常に良い答え、ありがとう。RPiカーネルが更新され、これがkswapを狂わせて得たものです。
ポールB

ありがとう、@ PaulB。システムの永続的なソリューションとして使用するcronジョブを回答に追加しました。
マーティンリュッグ

@Vegerが正しく指摘しているように、これは16.04でも機能します。現在、私は自分自身を使用しています。タグを追加しました。ありがとう!
マーティンリューグ

再びありがとう、@ Veger!-スクリプトのSha-Bangで欠落している感嘆符を修正しました。
マーティンリューグ16

1
「echo 1> / proc / sys / vm / drop_caches」は、私にとってCPU使用率が高いことを修正しました。昼と夜の違いです。kswapd0は100%CPUから0%になりました。理由の説明と永続的な解決策は素晴らしいでしょう。(補足:Linuxカーネル4.8.0-36-genericを16 GBメモリと16 GBスワップで実行しています。)
josephdpurcell
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.