zram を使用する場合の vm.swappiness の適切な値は何ですか?

zram を使用する場合の vm.swappiness の適切な値は何ですか?

私は、圧縮された RAM バックアップ スワップとしてコンピューターで zram を使用しています。システムが何かをスワップ アウトする必要がある場合、それを zram バックアップ スワップ ファイルにスワップすることは、メモリ内のデータを圧縮してスペースを解放することとほぼ同じです。これにより、ディスク バックアップ スワップに比べて、ほとんどの場合、スワップが非常に高速になります。このため、未使用のものをスワップ アウトするようにシステムに促すことで、実際にディスクにアクセスすることなく実行できるため、パフォーマンスが向上するのではないかと考えています。

では、zram を使用しているときに、たとえば 100 に設定するなどして試してみた人はいますかvm.swappiness? これは望ましいことでしょうか?

sysctl -w vm.swappiness=100

答え1

短い答えvm.swappiness=100適切な値zram の場合(少なくとも Linux 4.9 の Debian Stretch では、これが最も価値があると思います)

私はすでにテストを済ませていますvm.swappiness=100

できると思う簡単なテストどの値があなたにとって最適であるかを確認してください。

また、私はもう一つの簡単なプログラムこの質問をテストします。 x 私のマシンでは、非常に低いvm.swappiness値(などvm.swappiness=1)では明らかに応答性の問題が発生します。

について:SwapCached/proc/meminfo

まず、vm.page-cluster=0これを試してくださいSwapCachedスワップインによる無駄な処理を削減できるかもしれません。

SwapCachedは、非ZRAMスワップデバイスと同様にZRAMを高速化できます。

SwapCached必要に応じて再利用(無料)できます。

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$ 

答え2

swappiness を高く設定することはあまりお勧めしません。カーネルの一般的なメカニズムでは、実行中の他のタスクのためにメモリを解放するためにページ (メモリのチャンク) をスワップに格納します。

最初の「問題」は、カーネルが n ページを解放しようとすると、m ページ (m < n、m は n を保持するために必要な圧縮ページ数) が RAM に新しく作成されることです。これがカーネルに支障をきたすかどうかはわかりません。

いずれにしても、スワップにページがある場合、後でそのページの一部をスワップに保持したままアプリケーションを使用する可能性があります。カーネルはそれらのページを物理メモリに戻しますが、スワップから削除することはありません(標準的なスワップでは、キャッシングそのため、アプリケーションがバックグラウンドに戻ったときに、カーネルはそれらのページを低速スワップに書き戻す必要がありません。ただし、zram の場合、メモリ内に zram 内の m ページとメモリに戻された n ページが存在するため、これはおそらく賢明なトリックではありません。

カーネルには通常、処理を実行するために使用できる「合計メモリ」があります。zram を追加すると、ディスク ベースのスワップと同様に「スワップ」メモリのみがカウントされますが、実際の「合計メモリ」は減少し、カーネルはそれを予期していません。このため、奇妙で望ましくない動作が発生する場合があります。

zram では、メモリが圧迫されているときにカーネルがこの領域にスワップしすぎないようにするのがよいでしょう。また、実際のハード ディスク スワップ パーティションを少なくとも zram の最大サイズよりも大きくしておく必要があります。そうすることで、システムが OOM に陥ることがなくなり、同時にfree! によって報告される空き領域が十分にあることがわかります。

答え3

https://wiki.archlinux.org/title/Zram#swap_on_zram の最適化

これらの値はPop!_OSが使用するもの. Pop!_OS GitHubプルリクエストには、r/Fedora のユーザーによるテスト、vm.page-cluster = 0 が理想的であると判定しました。また、swappiness 値が高いことが理想的であることも判明しました。これは、カーネルドキュメント:

デフォルト値は 60 です。zram や zswap などのメモリ内スワップや、ファイルシステムよりも高速なデバイスにスワップがあるハイブリッド セットアップの場合は、100 を超える値を検討できます。たとえば、スワップ デバイスに対するランダム IO がファイルシステムからの IO よりも平均で 2 倍高速である場合、swappiness は 133 (x + 2x = 200、2x = 133.33) になります。

答え4

メモリがいっぱいのときは、ページを (ディスクに) スワップ アウトする必要があります。メモリがいっぱいのときにページをスワップ アウトする場所を作成するためにメモリを使用している場合、圧縮によって違いが出る場合を除いて、目的を達成できないと考えられます (その場合は、スワップを経由せずにメモリを直接圧縮するのが自然です)。コンピュータはメモリの速度に比べて圧縮と解凍がますます高速になっているため、これをベンチマークする必要があると思います。

関連情報