質問: なぜスワップオフがとても遅いのですか? 私のスワップ/ハードウェア/ドライバーで何か奇妙なことが起こっていると思います。スワップサイズをswapoff、lvresize、次にswaponずつ増やします。私がやったときswapoff /dev/swapdev、コマンドは約3.5gbのスワップされたページをメモリに移動するのに8分19秒かかりました。無料のramがswapoffを実行する前にスワップの使用量よりも大きいことを確認しました。これは実行中もtrueのままでした。ssd hddを搭載したintel core i5ラップトップを持っています。プロセッサはswapoffの前は10%未満でした。チェックインしたとき、swapoffは70%以上のcpuを使用していました。ジャーナルにはずっと興味深いものはありませんでした。ディスクからメモリに3.5gをシャントするのにかかると予想されるおおよその時間は次のとおりです。$ time dd if=/dev/urandom of=/tmp/del bs=1m count=3500 3500+0 records in 3500+0 records out 3670016000 bytes (3.7 gb, 3.4 gib) copied, 23.7288 s, 155 mb/s real 0m24.789s user 0m0.000s sys 0m22.743s 私は実行していますlinux svelte 4.9.53-1-manjaro #1 smp preempt thu oct 5 15:11:15 utc 2017 x86_64 gnu/linuxコマンドがとても長くかかる理由は何ですか?これはより大きな問題の一部である可能性がありますが、これが間違いなく最初に私が指摘できる最初のことです。
回答: スワップオフが実際に行うことはありません。実行中のマシンでスワップを行うスワップスペースの廃止は非常に複雑です。 8分で3.5gはおそらく非常に高速です+期待どおりに動作しています。swapoffの実行は、単にコードをディスクからメモリに移動するだけではありません。スワッピングしたら...まあ...スワッピングします。これは、osのメモリが不足していることを意味します+スワップデバイスへのディスクi/o +他のファイルシステムへのディスクi/o +多分ウォッチドッグまたはsystemd自動再起動が関与している場合、oom(メモリ不足キラー)が実行を開始し、次にoomされたプロセスのスラッシュが再起動します。システムがスワップしている場合、それはスワップがシステムを存続させる唯一の方法であることを意味します。スワップスペースを強制終了すると、システムはスワップスペースを使用できなくなるため、osは通常のファイルシステムのコードをロードし、メモリが使い果たされたときにコードを削除し、最適化されたrawディスクを介して高速スワップスペースからコードをプルする必要があります。読み取り、すべてのコードは、ディレクトリウォークを使用して、通常のファイルシステムから分離する必要があります。これは、スワップ領域から取得するよりもはるかに多くのリソースを消費します。スワップしているシステムでスワップオフを実行すると、通常、このプロセスに数時間かかる状況が発生します+場合によってはマシンがクラッシュします。何らかの理由でスワップデバイスを廃棄する必要がある場合は、最初にファイルシステムベースのセカンダリスワップスペースを作成し、この新しいスワップスペースに対してswaponを実行してから、古いスワップデバイスでswapoffを実行することをお勧めします。このアプローチをとれば、システムは常に存続します。