ハクソク

世界を動かす技術を、日本語で。

ZswapとZramの神話を解明する

46日前原文(chrisdown.name)

概要

  • zswap は多くのケースで推奨される圧縮スワップ技術
  • zram は特殊な用途や制約がある場合のみ利用推奨
  • zswapは カーネルのメモリ管理と連携 し、自動的にディスクスワップと階層化
  • zramは RAM上の圧縮ブロックデバイス で、容量超過時の自動退避なし
  • サーバやデスクトップでの 使い分けポイント や注意点を解説

zswapとzramの基本的な違い

  • zswap はカーネルのスワップ処理の前段に配置され、ページをRAM内で圧縮保存
    • 圧縮RAMプールが満杯になると、 自動的にコールドデータをディスクへ退避
    • メモリ管理サブシステムと密接に連携し、 負荷分散や階層化が容易
  • zram は圧縮RAMブロックデバイスとして動作
    • swap領域として使うと、 容量制限を超えると自動退避なし
    • 容量が一杯になるとOOM（Out Of Memory）や、 低優先度スワップへのフォールバック
    • 主に 組み込み機器・ディスクレス環境・特殊なセキュリティ要件 向け

zswap推奨の理由

  • ディスクスワップが利用可能な環境 では、zswapの自動階層化が有効
    • ホットデータは圧縮RAM、コールドデータはディスクへ
    • メモリ圧迫時もシステムが滑らかに劣化
  • zramはディスクスワップと併用非推奨
    • zramが高速RAMをコールドページで埋め、 アクティブな作業セットが遅いディスクへ追いやられる
    • 圧縮スワップがない方がマシなケースも

zramの適切な利用ケース

  • ディスクを持たない組み込み機器 やRaspberry Pi等
  • 極端にメモリが制約された環境
  • 永続ストレージに機密データを残したくない場合
  • デスクトップやサーバでは 推奨されない

zram利用時の注意点

  • ユーザー空間OOMマネージャ （systemd-oomdやearlyoom）とセットで使うべき
    • カーネルのOOM Killerは発動までに長時間フリーズすることがある
  • サーバ用途では cgroupによるメモリ隔離が効かない 等、運用上のデメリット

カーネルアーキテクチャの違い

  • zram はカーネルから通常のブロックデバイスとして扱われる
    • swap優先度やページクラスタ（vm.page-cluster）等の既存チューニングがそのまま適用
    • ページの局所性が失われ、 不要なページキャッシュ汚染が発生
  • zswap はカーネルのメモリ管理経路に直接統合
    • ページのホット/コールド判定が可能
    • プールが満杯になると 自動的にディスクへ退避するワーカが動作

LRU逆転（LRU inversion）の罠

  • swap優先度をzramに高く設定しても 自動階層化とは全く異なる
  • zramが先に埋まり、 コールドページが高速RAMを占有し続ける
  • アクティブな作業セットが遅いディスクへ追いやられ、 パフォーマンスが著しく低下

まとめ・推奨事項

  • zswapを優先的に利用
  • zramは特殊な理由がある場合のみ
  • ディスクスワップとzramの併用は 避ける
  • zramを使う場合は OOM対策を必ず実施
  • サーバやcgroup隔離が必要な環境では zswap一択

参考

  • zswap/zramの詳細はLinuxカーネルドキュメントや各ディストリビューションの公式ガイド参照
  • 組み込み用途や特殊要件は個別検証推奨

Hackerたちの意見

昔、ノートパソコンに初期のSSDを使ってたとき、スワップをzramに設定してたんだけど、みんなから「SSDが壊れるからスワップはやめとけ」って言われてた。設定がめんどくさかったな。

ここにいるユーザーで、ストレージのレベル2サポートもやってるよ。この記事にはしっかりした論理と、ちょっと違うと思う前提が含まれてる。しっかりした論理：スワップに使えるデバイスがあるなら、zswapを優先すべき。しっかりした論理：zramと他のスワップを組み合わせるのは良くない（zramがメモリ内で無駄になるから）。私の観察に基づくアドバイス：zramはユーザースペースのOOMキラーと組み合わせると最適に機能する。大胆な前提：SSDを持っている人はみんなスワップに使えるデバイスを持っている。これは単純に間違いで、「SSDの劣化」論とは関係ない。多くの消費者向けSSD、特にDRAMなしのやつ（例：Apacer AS350 1TB、Crucial SSDにも見られる）では、同期書き込みの際に10秒以上のレイテンシスパイクが頻発する。これはどのHDDよりもひどい。もしDRAMなしの消費者向けSSDしか持っていないなら、zramを使った方がいいよ。

└

読んでくれてありがとう、そして批評も！君が言ってることは確かに本当の問題だけど、少し反論したいな。結果は君が思ってるのとは逆になることが多いと思う。ここでの逆説的なことは、ディスクスワップを持っていると、実際にはディスクI/Oが減ることがあるってこと。実際、これは私たちのストレージ層の中で非常に重要で、運用の根幹に関わってる。今言うと「なんだそれ？」って思うかもしれないけど、聞いてほしい :-) zramだけの設定だと、zramがいっぱいになると、匿名ページが行き場を失う。カーネルはディスクスワップがないからそれをディスクに追い出せない。だから、メモリを解放する必要があるとき、ファイルキャッシュを回収するしか選択肢がない。カーネルに匿名メモリとファイルバックメモリのどちらが冷たいかを選ばせず、ファイルキャッシュだけを回収させると、最終的にはディスクアクティビティを避けるために必要だったファイルキャッシュを回収することになってしまう。その結果、同じ遅いDRAMなしのSSDに読み書きが行くことになる。記事の中で、zswapを有効にすると、スワップなしと比べてディスク書き込みが最大25%減ることがあるって言ったけど、もちろん正確な数字はワークロードによって変わる。でも、時間が経つにつれて冷たい匿名ページが蓄積されるほとんどのワークロードでこの方向性は当てはまるし、BMCやサーバー、デスクトップ、VRヘッドセットなどの制約のある環境でも確認してる。だから、逆説的に君のケースでは、適切なサイズのスワップデバイスを使うことでzswapがディスクI/Oを減らすこともあるかもしれない。もしそうじゃないなら、それがまさに私たちがmm側を改善するためのリアルなデータで、ぜひ教えてほしいな :-)

└

反論：zswapの書き戻しをほとんど無効にできるから、ハイバネーションのときだけスワップパーティションを使うことになるよ。[1]https://wiki.archlinux.org/title/Power_management/Suspend_an...

└

もうそのクソSSDをゴミ箱に捨てて、ちゃんとしたのを買った方がいいよ。OOMになるのは常にコストがかかるし。もしクソSSDを使わなきゃいけないなら、スワップサイズを大幅に増やして、ドライブに余裕を持たせて、間接的にオーバープロビジョニングするのがいいよ。

└

多くの消費者向けSSD、特にDRAMなしのもの（例: Apacer AS350 1TB、Crucial SSDでも見かける）では、同期書き込みの際に10秒以上のレイテンシスパイクが定期的に発生するんだ。こういうSSDでこの動作を確実に示すためにおすすめの実験はある？（理想的には特定のSSDが影響を受けていないと自信を持てるように）。例えば、10分間ずっと書き込み続けるだけで、O_DIRECTを使って個々の書き込みのレイテンシを簡単に測れるの？特定の並行性のレベルが必要？それとも読み書きの混合負荷が必要？小さな領域への繰り返し書き込みと大きな領域への書き込み（またはリマッピングが関係ない場合）で違いはある？これってfioで簡単にできること？SSDの容量がどれだけ書き込まれていてTRIMされていないかといった長期的な状態に依存する？それから、こういうSSDを購入する前に何を知っておけばいいの？影響を受けるモデルについて言及してたよね。DRAMなしについても言ってたけど、消費者向けSSDのスペックシートには一般的にどれくらいのDRAM（あれば）を持ってるか書いてあるの？影響を受けない消費者モデルがあればいいけど、必要ないならエンタープライズ価格に飛びつくのはもったいない。あまり使ってない消費者向けSSDがいくつかあるから、そういう動作があるか見てみたいな。

└

多くの消費者向けSSD ... 同期書き込みの際に10秒以上のレイテンシスパイクが定期的に発生する これは「定期的に」っていうのはかなりの誇張だね。ほとんどの人はこの失敗モードを実際に見たことがないと思う。もしそれが重い書き込み負荷の下でしか発生しないなら、それはスワッピングの結果として起こるべきことじゃないよ。

└

その仮定は単純に間違ってるし、「SSDの摩耗」論争のせいでもない。多くの消費者向けSSD、特にDRAMなしのやつ（例えば、Apacer AS350 1TBやCrucial SSDなど）は、同期書き込みの際に、セルを管理する方法のせいで10秒以上のレイテンシスパイクを定期的に発生させる。これをオーバープロビジョニングでどの程度軽減できるか知ってる？例えば、ドライブの50%だけをパーティション分けして、残りをコントローラーの「スクラッチスペース」として空けておくみたいな。

└

その仮定は単純に間違ってるし、「SSDの劣化」っていう理由じゃないよ。特にDRAMなしの消費者向けSSD（例えば、Apacer AS350 1TBやCrucialのSSDなど）は、同期書き込みの際に、セルの管理方法のせいで10秒以上のレイテンシスパイクを頻繁に引き起こすんだ。これはどんなHDDよりもひどい。もしDRAMなしの消費者向けSSDしか持ってないなら、zramを使った方がいいよ。NVMeではDRAMなしの問題はあまり気にしなくていいけどね。NVMeはホストメモリバッファを使ってシステムRAMを論理処理に使えるから、NANDに頼るよりもずっと速いんだ。SATAではDRAMなしは全ての面で悪いから、できるだけ使わない方がいいし、NVMeでは悪い品質のドライブと良い品質のドライブの違いが大きい。DRAMがあることは、そのドライブが良いものであることの良い指標になるけど、DRAMがないからといって必ずしも性能が悪いわけではないんだ。世代間でドライブを比較すると、DRAMなしの方が、負荷のかかる状況でも古いDRAM付きのドライブよりも良いパフォーマンスを発揮することが多いよ。

└

安いQLCドライブは、かなり満杯になり始めると超遅くなって、ガベージコレクション（SLC書き込みをQLCに集めるのが多分10MB/sくらい）を始めるんだ。個人的には、これはOSドライブには十分じゃないと思う。

zswapがバックアップキャッシュなしで設定できたら、zramを完全に置き換えられるのに。少し違うシステムが二つあるのは変だよね。ディスクのスワップがいっぱいになるのと、RAMのスワップがいっぱいになるのに実際の違いはないし、どちらにしても何かがOOMキルされる必要がある。設定を簡素化すれば、ほとんどのディストロでデフォルトで有効にしやすくなると思う。ChromeOS以外の一般的なLinuxディストロがこの点でMacやWindowsより遅れてるのはちょっと逆だよね。

└

すごく同意する。ディストロはまだこれを間違えることが多い気がする（証拠として、Ubuntu、PopOS、Fedoraはそれぞれかなり違うスワップ設定を持ってる）。

└

実はこれ、今まさに取り組んでることなんだ！Nhat Phamが「バーチャルスワップスペース」っていうパッチシリーズに取り組んでて、zswapをバックストアから完全に切り離すんだ。目標は、異なる失敗モードを持つ二つのシステムを維持するんじゃなくて、適切なMM統合を持つ単一の実装にまとめること。数ヶ月以内に出る予定だよ、期待してる。

└

zswapがバックキャッシュなしで設定できたらいいのに 今日は/dev/ram0をスワップデバイスとして使うことでこの動作を実現できるけど、すごく面倒だし、ほぼ確実に悪いアイデアだよ。

zramを使うと、zram-generator[0]を使えば全部やってくれるし、systemdジェネレーターをインストールする以外に何も設定しなくていい。これって、いくつかのディストロではデフォルトでインストールされてるんだ。zswapに相当するものはあるのかな？そうでないなら、ほとんどの人が最適じゃなくてもzramを使うのも仕方ないよね。[0]: https://crates.io/crates/zram-generator

└

これ、バッシュスクリプトにすればよかったのに…

└

echo 1 > /sys/module/zswap/parameters/enabled これはTFAに載ってるよ。

└

カーネル引数が主な方法だよね: https://wiki.archlinux.org/title/Zswap#Using_kernel_boot_par... ちょっとした問題があって、ブート時にzstdを使わせるのがうまくいかなかった。バグなのか、Debian特有のものなのかは分からないけど。結局、他の理由で自分でカーネルをコンパイルしたら、デフォルトでzstdが使えるようになった。でも、そうじゃなかったらスタートアップスクリプトに追加しないといけなかった。

└

便利なツールだけど、デフォルトで合理的なzramサイズを設定してくれないし、ページクラスタリングみたいな他のことにも手を付けないから、「何も設定しなくていい」ってのは、最適からかなり遠いのが気にならない人にしか当てはまらない。

└

Archではzswapがデフォルトで有効になってるけど、バックディスクスワップがないと何も機能しないよ。

最近これについても書いたよ: https://www.theregister.com/2026/03/13/zram_vs_zswap/ zswapの方がzramより好きだし、記事の最後にリンクしたように、私だけじゃないんだ: https://linuxblog.io/zswap-better-than-zram/ もしかしたら考えすぎかもしれないけど、この神話についての話が私の記事への反応なんじゃないかって思ってる。

zswapとzramのあまり評価されていない側面の一つは、圧縮アルゴリズムの選択と圧縮されるデータとの相互作用なんだ。LZ4（両方のデフォルト）は、比率を犠牲にして速度を最適化してる — 通常、メモリページで2-2.5倍。zstdはそれを3-3.5倍に押し上げることができるけど、ページフォルトごとのCPUコストがかなり高くなる。面白いトレードオフは、メモリページはファイルとは根本的に異なるってこと。ポインタサイズの値やスタックフレーム、ヒープメタデータがたくさん含まれてて、シンプルなLZバリアントが実は複雑なアルゴリズムに比べて驚くほど良く機能するデータパターンなんだ。zstdを超える（例えば、BWTベースやコンテキストミキシング）ことは、メモリページではリターンが減少し、レイテンシを悪化させることになる。だから、本当の質問は「zswap対zram」だけじゃなくて、「あなたのワークロードのメモリアクセスパターンに応じて、圧縮ページごとにどれだけのCPUを使うつもり？」ってこと。レイテンシに敏感なワークロードでは、zswapの書き戻しを使ったLZ4が最強だよ。

└

LLMによって書かれたコメントはこのサイトでは許可されていません。

zramデバイスは物理RAMの100%にサイズを合わせて、最大8GBまで。これがどういう意味か疑問に思うかもしれないけど、RAMのサイズと同じくらいのスワップデバイスを持つってどういうこと？ zramのサイズは非圧縮データに適用されるから、実際の使用量は動的に増えていく（静的な管理も含む）。ほとんどのメモリはうまく圧縮されるから、物理RAMよりも大きいzramデバイスサイズを持つのがいいかもね。

OOMデーモンのシンプルな代替策として、MGLRUのスラッシング防止を有効にするのもありかも: https://www.kernel.org/doc/html/next/admin-guide/mm/multigen... 低RAMのスマホで、ディスクスワップなしでzramを200%のRAMサイズに設定して使ってるんだけど、ちょっとした調整（さっきのクラスタリングノブみたいな）をすれば、まあまあうまくいくよ。予防できるキルがあるのは気にしないけど、準備ができたらディスクレスのzswapに切り替えるつもり。

zramがカーネルに登場してから使ってるけど、同じ優先度で「petard」とディスクバックアップスワップを使ってる。今は詳細は覚えてないけど、何年も前のzswapはハイバネーションを「うまく」処理できなかった（できる範囲でね）。zram+別のハイバネーションで-XXXの優先度よりも良くはなかった。でも、その設定にはいくつかの注意点があって、ハイバネーション後にはディスクキャッシュが使われて手動でフラッシュしないといけないことがある。zram-generator（使ってるなら）も、リジューム時にはまだ準備ができてないから、そんな感じだったと思う。すごくきれいに書かれた投稿だから、これからはzswapを使ってみようと思う。

cleancacheの一部としてのzswapのこと？でも、それはカーネルから完全に外れたんじゃない？それに、zramはバックデバイスのサポートを得たし。ところで、ほとんどのzramのチュートリアルは間違ってるよ。アイドルページを手動でマークして、定期的に/sys/block/zramX/idleと/sys/block/zramX/writebackに書き込んで書き戻しを開始する必要がある。そうしないと、zramはバックデバイスに何も書き込まない。カーネルのドキュメントに記載されてるけど、自動で動くと思ってると勘違いするかも。スワップをそんなバックデバイスに変換することもできるけど、その場合はswaponはしない（fstabから削除するだけ）し、フォーマット（mkswap）も必要ないよ。