kswapd0はCPUの99.9%を使用しています。トップに表示されているように、問題は今日ゲームで発生し、6分後に初めて消え、約20分間実行されました。これはどのように修正可能で、何が原因ですか?
プロセス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の間で情報が移動され、情報の要求がすべて同時に処理されます。この問題を解決するには?
RAMが完全に使い果たされた場合にのみ、SWAPにデータを移動するようkswapd0に指示します。これは、SWAPの問題を解決するための最も効果的な方法です。走る
echo vm.swappiness=0 | Sudo tee -a /etc/sysctl.conf
0
は、SWAPが使用される100
の残りの割合です(0%RAMが残っている場合、SWAPはデータの取り込みを開始します)。また、geditやnanoなどを使用して毎回このコマンドを最後に追加する代わりに、好みに合わせて/etc/sysctl.confを編集することもできます。ただし、このファイルはルート所有です。再起動すると設定が完了しました!
それがあなたにできる最高のことです。他の人はスワップを完全に無効にすると言うかもしれませんが、それは危険であり、私はそれをお勧めしません。これにより、メモリリークや実行中のアプリケーションが多すぎる場合、システム全体がフリーズする可能性があります。 SWAPはRAMのフェイルセーフであることを認識してください。 RAMほど高速でも効率的でもありませんが、Windowのページファイルよりも優れています! (同じ目的を達成します)
編集:SWAPの詳細に興味がある場合は、 here を参照してください。
私には、カーネル3.19.0-50-generic(およびそれ以前)がVMware vmで実行されている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
再起動により問題が解決しました-一時的に。
serverfault(スワップが使用されている場合、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
しかし、実際の理由はまだわかっておらず、ネット上で適切な説明をしていないので、これは永続的な解決策ではありません。実際には、選択された answer が永続的な解決策になる可能性があります。 (sysctlを有効にするための)リブートが常に可能であるとは限らないため、将来の参照用にこれを追加したかっただけです。
他の解決策は、THPをmadvice
またはnever
に設定することです( poige's のコメントへのコメント answer 、 How do I I 「/ sys/kernel/mm/transparent_hugepage/enabled」 および Transparent Huge Pages(THP)の無効化 )で参照されているMongoDBマニュアルを変更します
「永続的な」ソリューションとして、次のバッチを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