zswapとmax_pool_percent = 100でzram LRUの逆転を防止

Question

Zramを使用する主な欠点は LRU反転です。

古いページは優先順位の高いzramに入り、すぐに埋められますが、新しいページは遅い[...]スワップにスワップインおよびスワップアウトされます。

zswap documentation は、zswapがこれに悩まされないことを示しています：

Zswapは、Frontswap APIを介して圧縮用のページを受信し、LRUベースで独自の圧縮プールからページを追い出し、圧縮プールがいっぱいになった場合にそれらをバッキングスワップデバイスに書き戻すことができます。

max_pool_percentを100に設定することで、zramのすべての利点と完全に圧縮されたRAM=を利用できますか？

Zswap seeks to be simple in its policies. Sysfs attributes allow for one user controlled policy: * max_pool_percent - The maximum percentage of memory that the compressed pool can occupy.

ここではデフォルトのmax_pool_percentは指定されていませんが、 Arch Wikiページは20であると述べています。

解凍によるパフォーマンスへの影響とは別に、max_pool_percentを100に設定することには危険/欠点がありますか？

それは、改良されたswap-backed zramを使用するように動作しますか？

Jake F · Accepted Answer

あなたの質問に答えるために、私は最初に一連の実験を行いました。最後の答えは太字になっています。

実施した実験：

1) swap file, zswap disabled 2) swap file, zswap enabled, max_pool_percent = 20 3) swap file, zswap enabled, max_pool_percent = 70 4) swap file, zswap enabled, max_pool_percent = 100 5) zram swap, zswap disabled 6) zram swap, zswap enabled, max_pool_percent = 20 7) no swap 8) swap file, zswap enabled, max_pool_percent = 1 9) swap file (300 M), zswap enabled, max_pool_percent = 100

実験前のセットアップ：

VirtualBox 5.1.30
Fedora 27、xfceスピン
512 MB RAM、16 MBビデオRAM、2 CPU
linuxカーネル4.13.13-300.fc27.x86_64
デフォルトのswappiness値（60）
一部の実験（ddを使用）で使用できるように、空の512 MBスワップファイル（実験9では300 MB）を作成しましたが、まだswaponを作成していません
すべてのdnf * systemdサービスを無効にし、watch "killall -9 dnf"を実行して、dnfが実験中または何かの間に自動更新を試みず、結果が極端にスローされないようにしました

実験前の状態：

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 280 72 8 132 153 Swap: 511 0 511 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 74624 8648 127180 0 0 1377 526 275 428 3 2 94 1 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 102430 688 3593850 67603 3351 8000 1373336 17275 0 26 sr0 0 0 0 0 0 0 0 0 0 0

実験中に異なる設定につながる後続のスワップオン操作などにより、これらの値の約2％以内の分散が生じました。

実験操作は次のもので構成されています。

Firefoxを初めて実行する
約40秒待つか、ネットワークとディスクのアクティビティが停止するまで（どちらか長い方）
実験後に次の状態を記録します（Firefoxが実行されたままにしましたが、Firefoxがクラッシュした実験7と9を除きます）。

実験後の状態：

1）スワップファイル、zswap無効

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 287 5 63 192 97 Swap: 511 249 262 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 255488 5904 1892 195428 63 237 1729 743 335 492 3 2 93 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 134680 10706 4848594 95687 5127 91447 2084176 26205 0 38 sr0 0 0 0 0 0 0 0 0 0 0

2）スワップファイル、zswap有効、max_pool_percent = 20

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 330 6 33 148 73 Swap: 511 317 194 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 325376 7436 756 151144 3 110 1793 609 344 477 3 2 93 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 136046 1320 5150874 117469 10024 41988 1749440 53395 0 40 sr0 0 0 0 0 0 0 0 0 0 0

3）スワップファイル、zswap有効、max_pool_percent = 70

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 342 8 32 134 58 Swap: 511 393 118 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 403208 8116 1088 137180 4 8 3538 474 467 538 3 3 91 3 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 224321 1414 10910442 220138 7535 9571 1461088 42931 0 60 sr0 0 0 0 0 0 0 0 0 0 0

4）スワップファイル、zswap有効、max_pool_percent = 100

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 345 10 32 129 56 Swap: 511 410 101 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 420712 10916 2316 130520 1 11 3660 492 478 549 3 4 91 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 221920 1214 10922082 169369 8445 9570 1468552 28488 0 56 sr0 0 0 0 0 0 0 0 0 0 0

5）zramスワップ、zswap無効

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 333 4 34 147 72 Swap: 499 314 185 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 324128 7256 1192 149444 153 365 1658 471 326 457 3 2 93 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 130703 884 5047298 112889 4197 9517 1433832 21037 0 37 sr0 0 0 0 0 0 0 0 0 0 0 zram0 58673 0 469384 271 138745 0 1109960 927 0 1

6）zram swap、zswap enabled、max_pool_percent = 20

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 338 5 32 141 65 Swap: 499 355 144 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 364984 7584 904 143572 33 166 2052 437 354 457 3 3 93 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 166168 998 6751610 120911 4383 9543 1436080 18916 0 42 sr0 0 0 0 0 0 0 0 0 0 0 zram0 13819 0 110552 78 68164 0 545312 398 0 0

7）スワップなし

これらの統計を記録する時点では、この実験ではFirefoxが実行されていないことに注意してください。

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 289 68 8 127 143 Swap: 0 0 0 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 70108 10660 119976 0 0 13503 286 607 618 2 5 88 5 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 748978 3511 66775042 595064 4263 9334 1413728 23421 0 164 sr0 0 0 0 0 0 0 0 0 0 0

8）スワップファイル、zswap有効、max_pool_percent = 1

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 292 7 63 186 90 Swap: 511 249 262 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 255488 7088 2156 188688 43 182 1417 606 298 432 3 2 94 2 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 132222 9573 4796802 114450 10171 77607 2050032 137961 0 41 sr0 0 0 0 0 0 0 0 0 0 0

9）スワップファイル（300 M）、zswap有効、max_pool_percent = 100

Firefoxがスタックし、システムは依然としてディスクから激しく読み取りました。新しいスワップファイルが書き込まれたため、この実験のベースラインは異なります。

 total used free shared buff/cache available Mem: 485 280 8 8 196 153 Swap: 299 0 299 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 8948 3400 198064 0 0 1186 653 249 388 2 2 95 1 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 103099 688 3610794 68253 3837 8084 1988936 20306 0 27 sr0 0 0 0 0 0 0 0 0 0 0

具体的には、この変更の結果として、追加の649384セクターが書き込まれました。

実験後の状態：

[root@user-vm user]# free -m ; vmstat ; vmstat -d total used free shared buff/cache available Mem: 485 335 32 47 118 53 Swap: 299 277 22 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 7 1 283540 22912 2712 129132 0 0 83166 414 2387 1951 2 23 62 13 0 disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 3416602 26605 406297938 4710584 4670 9025 2022272 33805 0 521 sr0 0 0 0 0 0 0 0 0 0 0

2022272から余分な649384の書き込み済みセクターを差し引くと、1372888になります。これは、Firefoxが完全に読み込まれていないためと考えられる1433000（後述）未満です。

また、低いswappiness値（10と1）を使用していくつかの実験を実行したところ、すべてが過度のディスク読み取りでフリーズ状態に陥り、最終的なメモリ統計を記録できなくなりました。

観察：

主観的に、max_pool_percentの値が高いと、動作が遅くなりました。
主観的には、実験9のシステムは非常に遅く、使用できませんでした。
max_pool_percentの値が高いと書き込みの量が最小になり、max_pool_percentの値が非常に低いと書き込みの数が多くなります。
実験5と6（zramスワップ）は、firefoxがデータを書き込んだ結果、約62000セクターがディスクに書き込まれることを示唆しています。約1433000以上は、スワッピングのために書き込まれたセクターです。次の表を参照してください。
実験の中で最も少ない数の読み取りセクターをベースラインと仮定すると、スワップによって生じた余分な読み取りセクターの量に基づいて、実験を比較できます。

スワッピングの直接的な結果として書かれたセクター（およそ）：

650000 1) swap file, zswap disabled 320000 2) swap file, zswap enabled, max_pool_percent = 20 30000 3) swap file, zswap enabled, max_pool_percent = 70 40000 4) swap file, zswap enabled, max_pool_percent = 100 0 5) zram swap, zswap disabled 0 6) zram swap, zswap enabled, max_pool_percent = 20 -20000 7) no swap (firefox crashed) 620000 8) swap file, zswap enabled, max_pool_percent = 1 -60000 9) swap file (300 M), zswap enabled, max_pool_percent = 100 (firefox crashed)

スワッピングの直接的な結果としての余分な読み取りセクター（約）：

 51792 1) swap file, zswap disabled 354072 2) swap file, zswap enabled, max_pool_percent = 20 6113640 3) swap file, zswap enabled, max_pool_percent = 70 6125280 4) swap file, zswap enabled, max_pool_percent = 100 250496 5) zram swap, zswap disabled 1954808 6) zram swap, zswap enabled, max_pool_percent = 20 61978240 7) no swap 0 (baseline) 8) swap file, zswap enabled, max_pool_percent = 1 401501136 9) swap file (300 M), zswap enabled, max_pool_percent = 100

結果の解釈：

これは主観的であり、手元のユースケースにも固有です。動作は他のユースケースで異なります。
ZswapのページプールはRAM内のスペースを奪いますが、システムのページキャッシュ（ファイルバッキングページの場合）で使用できます。つまり、システムはファイルバッキングページを繰り返し破棄し、必要に応じて再度読み取り、その結果、過度の読み取り。
実験7の大量の読み取りは、同じ問題が原因で発生します。システムの匿名ページがRAMのほとんどを使用し、ファイルに基づくページをディスクから繰り返し読み取る必要がありました。
特定の状況では、zswapを使用して、スワップディスクに書き込まれるデータの量をゼロに近づけることができる場合がありますが、明らかにこのタスクには適していません。
システムがRAMに常駐して動作するためには、一定量の非スワップページが必要なため、[完全に圧縮されたRAM "にすることはできません。

個人的な意見と逸話：

ディスクの書き込みに関するzswapの主な改善点は、ページを圧縮するという事実ではなく、ページキャッシュを削減し、より多くの匿名のページを（圧縮形式で）RAMに効果的に保持する独自のバッファリングとキャッシングシステムを備えていることです。（ただし、私がLinuxを毎日使用している私の主観的な経験に基づいて、zswapとmax_pool_percentのデフォルト値を持つスワップとswappinessのシステムは、swappiness値よりも常に良好に動作し、max_pool_percentの値が高いzswapまたはzswapはありません）。
swappinessの値が低いと、残りのページキャッシュの量が少なくなりすぎて、過度のディスク読み取りが原因でシステムが使用できなくなるまで、システムの動作が向上するようです。高すぎるmax_pool_percentでも同様です。
zramスワップだけを使用して、メモリに保持する必要がある匿名ページの量を制限するか、zswapでディスクバックアップスワップを使用して、swappinessおよびmax_pool_percentのほぼデフォルト値を使用します。

編集：あなたの質問のより細かい点に答えるための可能な将来の作業は、zsmallocで使用されるzramアロケーターがzbudアロケーターでzswapアロケーターと圧縮方式でどのように比較されるか特定のユースケースを見つけることです。ただし、ドキュメントやインターネットで検索する項目を指摘するだけではありません。

編集2：echo "zsmalloc" > /sys/module/zswap/parameters/zpoolはzswapのアロケーターをzbudからzsmallocに切り替えます。上記の実験のテストフィクスチャを続行し、zramとzswap + zsmallocを比較すると、必要なスワップメモリがzramスワップまたはzswapのmax_pool_percentと同じである限り、読み取りと書き込みの量は非常に多くなります。 2つの間で似ています。事実に基づいた私の個人的な意見では、必要なzramスワップの量が実際にRAMに保持できるzramスワップの量よりも少ない限り、zramのみを使用するのが最善です。実際にメモリに保持できる以上のスワップが必要になった場合は、それを回避するためにワークロードを変更するか、zramスワップを無効にしてzswapをzsmallocとともに使用し、max_pool_percentをzramが以前にメモリで取得したもの（サイズ）に設定することをお勧めしますzram *圧縮率）。しかし、私は現在、これらの追加のテストを適切に書く時間はありません。