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


13

コンピューターでzramをRAMベースの圧縮スワップとして使用しています。システムが何かをスワップアウトする必要がある場合、それをzram-backedスワップファイルにスワップすることは、メモリ内のデータを圧縮してスペースを解放することとほぼ同等です。これにより、ディスクバックアップスワップと比較して、ほとんどの場合、スワップが非常に高速になります。このため、実際にディスクにヒットすることなく使用できるので、システムが未使用のものをより積極的にスワップアウトすることを奨励することによって、パフォーマンスがいくらか得られるのだろうか?

だから、だれかが、vm.swappinesszramの使用中に100 に設定するなど、いじくり回したことがありますか?これは望ましいでしょうか?

sysctl -w vm.swappiness=100

2
...これは素晴らしい質問です、私はいくつかのベンチマークは意見を削除し、事実を取得するためにだと思う
エルダーオタク

良いアイデアであり、zramは2012年に最後に使用してから改善された可能性があります:
Huygens

小さなテストを行いましたが、私が知る限り、zramの「予約済み」メモリはまだキャッシュとして使用されています。これが確認された場合、CPUサイクルを回避するためにスワップ性を低く保つことは理にかなっていると思いますか?
ビトー

回答:


2

swappinessを高くすることは本当にお勧めしません。カーネルの一般的なメカニズムは、スワップ(ページのメモリ)をスワップに配置して、他の実行中のタスクのためにメモリを解放することです。

カーネルがnページを解放したい場合の最初の「問題」、m(m <n、mはnを保持するために必要な圧縮ページの数)がRAMに新しく作成されます。ありません。

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

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

zramを使用すると、メモリが圧迫されているときにカーネルがこの領域に過度にスワップしないようにすることができます。また、少なくともzramの最大サイズよりも大きい実際のハードディスクスワップパーティションを常に用意して、システムがOOMを取得しないようにし、同時にfree


zramはRAMブロックデバイスを提供します。これらのブロックデバイスに書き込まれたものはすべて圧縮されます。zramブロックデバイスがスワップとして使用される場合、システムがメモリの一部を移動してスワップしようとすると、メモリがRAMの一部から別の部分に効果的に移動しますが、データは宛先にコピーされる前に圧縮されます。これは、安価なメモリ圧縮メカニズムとして効果的に機能し、メモリの量が限られているシステムの応答性を向上させます。... Linux 2.6.33以降、Zramはステージングを行っています。3.14では、zramはstagingからdrivers / block / zramに移動しました。
オタク長老

1
@ElderGeekまさに!そして、それが完全ではない理由を説明するために例を取り上げます。カーネルは64MBのRAMを削除しようとし、それらをzramスワップに入れます。圧縮された64MBチャンクは現在32MBです。その結果、メモリは64MBではなく32MB減少します。ここで、アプリケーションがメモリに64MBを戻す必要がある場合、カーネルコピー(および移動ではない)がメモリ内にチャンクを戻すとどうなります。RAMに64MB + zramに32MBが追加されました。コピーする理由 私の答えで説明したように、カーネルがページをキャッシュするためです。両方の動作は理想的ではありません。また、メモリが十分に圧縮可能でない場合、それはさらに悪化します。
ホイヘンス

まだテスト段階です。圧縮されていないRAMにコピーされたときに圧縮されたページを解放するためにzramが使用するキャッシュアルゴリズムを調整する方法が必要だと思います。
オタク長老

2012年まで何度か試してみました。そのとき、コンピューターは1GBのRAMに制限されていました。しかし、それ以来、私はそれを二度と使用しませんでした。RAMが十分にあるため、スワップを使用しなくなりました。当時Firefoxでzramを使用していたとき、RAMが少ししかなかったので、すぐに「スワップ」を始めました。そしてすぐに、多くのクラッシュを伴う応答のないシステムになりました。zramを使用しないと、痛みを伴うほど遅くなりましたが、少なくとも安定していました。私の問題は、おそらくメモリページを常に圧縮/圧縮解除していたことです。
ホイヘンス

はい、私の結果はいくらか似ていました。8GBのシステムでは、エンコードジョブ中に複数のVMを起動することでOOMを強制できました。zswapの使用経験はありますか?これは、私が読んだものに基づいた実行可能な代替案のようです。
オタク長老

2

簡単な答え:zramにvm.swappiness=100適切な値です(少なくとも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$ 

0

メモリがいっぱいになったら、ページを(ディスクに)スワップアウトする必要があります。メモリがいっぱいのときにページをスワップアウトする場所を作成するためにメモリを使用している場合、圧縮によって違いが生じる場合を除き、目的に反すると思います(そして、メモリを通過する代わりに直接メモリを圧縮するのが自然でしょう)スワップ)。コンピューターはメモリ速度と比較して圧縮と解凍の速度がますます速くなっているため、これをベンチマークする必要があると思います。


システムのメモリが不足している場合、zram-backed swap自体が非常に役立つことがわかりました。地獄のスワッピングに完全に巻き込まれ、再起動する必要がなくなりました(大規模なデータセットを分析しているため、24 GBのメモリが必要です)。私は、vm.swappiness値がディスクバックアップスワップ用に調整されているかどうか、そして主にzramバックアップスワップを使用する場合に変更する必要があるかどうかについて疑問に思っています。
ライアンC.トンプソン

1
「ますます高速に」?オンザフライ圧縮は、過去10年以上、直接ディスクI / Oよりも優れたパフォーマンスを発揮しています(メモリアクセスより高速になることは決してありません-それはポイントではありません)
-symcbean

symcbean、「メモリ速度と比較して」を忘れました。不一致はどこですか?
アレクサンダー

symcbeanのポイントは、圧縮メモリバックアップページ(zram)の目標は、物理メディアへのスワップを置き換えることだと思います。「メモリを直接圧縮するのが自然」ではない理由は、メモリのどの部分をいつ圧縮できるかをアプリケーションが判断しなければならないという複雑さが伴うためです。VMサブシステムはこれを実装するのにはるかに簡単な場所です。zramの恩恵を受けるワークロードには、ワーキングセットにないページがあり、簡単に圧縮できます。
ダニエルパパシアン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.