Der größte Nachteil der Verwendung von ZRAM istLRU-Inversion:
ältere Seiten gelangen in den ZRAM mit höherer Priorität und füllen ihn schnell, während neuere Seiten in den langsameren [...] Swap-Speicher ein- und ausgelagert werden.
Derzswap-Dokumentationsagt, dass zswap darunter nicht leidet:
Zswap empfängt Seiten zur Komprimierung über die Frontswap-API und kann Seiten auf LRU-Basis aus seinem eigenen komprimierten Pool auslagern und sie auf das zugrunde liegende Swap-Gerät zurückschreiben, falls der komprimierte Pool voll ist.
max_pool_percentKönnte ich durch die Einstellung auf alle Vorteile von ZRAM und einen vollständig komprimierten RAM nutzen 100?
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.
Hier ist kein Standardwert max_pool_percentangegeben, aber dieArch Wiki-Seitesagt, dass es so ist 20.
Gibt es, abgesehen von den Auswirkungen der Dekomprimierung auf die Leistung, irgendwelche Gefahren/Nachteile bei der Einstellung max_pool_percentauf 100?
Würde es so funktionieren, als würde man einen verbesserten Swap-Backed-ZRAM verwenden?
Antwort1
Um Ihre Frage zu beantworten, habe ich zunächst eine Reihe von Experimenten durchgeführt. Die endgültigen Antworten sind am Ende fett gedruckt.
Durchgeführte Experimente:
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
Aufbau vor dem Experiment:
- VirtualBox 5.1.30
- Fedora 27, XFCE-Spin
- 512 MB RAM, 16 MB Video-RAM, 2 CPUs
- Linux-Kernel 4.13.13-300.fc27.x86_64
- Standardwert
swappiness(60) - eine leere 512 MB große Auslagerungsdatei (300 MB in Experiment 9) für die mögliche Verwendung während einiger Experimente (mit ) erstellt, aber noch
ddnichtswapon - alle dnf*-Systemd-Dienste deaktiviert, ausgeführt,
watch "killall -9 dnf"um sicherer zu sein, dass dnf während des Experiments nicht versucht, automatisch zu aktualisieren oder so etwas und die Ergebnisse zu sehr verfälscht
Zustand vor dem Experiment:
[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
Durch die anschließenden Vertauschungen etc., die zu den unterschiedlichen Einstellungen im Versuch führten, ergaben sich Abweichungen von ca. 2% von diesen Werten.
Der Versuchsablauf bestand aus:
- Firefox zum ersten Mal ausführen
- Warten Sie etwa 40 Sekunden oder bis die Netzwerk- und Festplattenaktivität endet (je nachdem, was länger dauert).
- Notieren Sie den folgenden Status nach dem Experiment (Firefox wurde weiterhin ausgeführt, mit Ausnahme der Experimente 7 und 9, bei denen Firefox abstürzte):
Zustand nach dem Experiment:
1) Auslagerungsdatei, zswap deaktiviert
[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) Auslagerungsdatei, zswap aktiviert, 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) Auslagerungsdatei, zswap aktiviert, 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) Auslagerungsdatei, zswap aktiviert, 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-Swap, Zswap deaktiviert
[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 aktiviert, 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) kein Tausch
Beachten Sie, dass Firefox zum Zeitpunkt der Aufzeichnung dieser Statistiken in diesem Experiment nicht ausgeführt wird.
[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) Auslagerungsdatei, zswap aktiviert, 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) Auslagerungsdatei (300 M), zswap aktiviert, max_pool_percent = 100
Firefox war hängen geblieben und das System las immer noch rasend schnell von der Festplatte. Die Ausgangsbasis für dieses Experiment ist eine andere, da eine neue Auslagerungsdatei geschrieben wurde:
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
Konkret wurden durch diese Änderung 649.384 zusätzliche Sektoren geschrieben.
Zustand nach dem Experiment:
[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
Wenn man die zusätzlichen 649384 geschriebenen Sektoren von 2022272 abzieht, erhält man 1372888. Das ist weniger als 1433000 (siehe später), was wahrscheinlich daran liegt, dass Firefox nicht vollständig geladen wird.
Ich habe auch einige Experimente mit niedrigen swappinessWerten (10 und 1) durchgeführt und sie blieben alle in einem eingefrorenen Zustand mit übermäßigen Festplattenlesevorgängen hängen, sodass ich die endgültigen Speicherstatistiken nicht aufzeichnen konnte.
Beobachtungen:
- Subjektiv
max_pool_percentführen zu hohe Werte zu Trägheit. - Subjektiv war das System im Experiment 9 so langsam, dass es unbrauchbar war.
- Hohe
max_pool_percentWerte führen zu der geringsten Anzahl von Schreibvorgängen, während sehr niedrige Wertemax_pool_percentzu der größten Anzahl von Schreibvorgängen führen. - Die Experimente 5 und 6 (ZRAM-Swap) lassen darauf schließen, dass Firefox Daten geschrieben hat, die etwa 62.000 Sektoren auf die Festplatte geschrieben haben. Alles über etwa 1.433.000 sind Sektoren, die aufgrund von Swapping geschrieben wurden. Siehe die folgende Tabelle.
- Wenn wir davon ausgehen, dass die niedrigste Anzahl gelesener Sektoren unter den Experimenten die Basis darstellt, können wir die Experimente anhand der Anzahl zusätzlicher gelesener Sektoren vergleichen, die sie durch Swapping verursacht haben.
Geschriebene Sektoren als direkte Folge des Swappings (ca.):
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)
Zusätzliche Lese-Sektoren als direkte Folge des Swappings (ca.):
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
Interpretation der Ergebnisse:
- Dies ist subjektiv und auch spezifisch für den vorliegenden Anwendungsfall; in anderen Anwendungsfällen kann das Verhalten abweichen.
- Der Seitenpool von Zswap nimmt Speicherplatz im RAM weg, der andernfalls vom Seitencache des Systems (für dateibasierte Seiten) verwendet werden könnte. Dies bedeutet, dass das System dateibasierte Seiten wiederholt verwirft und sie bei Bedarf erneut liest, was zu übermäßigen Lesevorgängen führt.
- Die hohe Anzahl an Lesevorgängen in Experiment 7 ist auf dasselbe Problem zurückzuführen: Die anonymen Seiten des Systems beanspruchten den größten Teil des RAM und dateibasierte Seiten mussten wiederholt von der Festplatte gelesen werden.
- Unter bestimmten Umständen ist es möglich, die auf die Swap-Disk geschriebene Datenmenge mithilfe von nahezu Null zu minimieren,
zswapaber für diese Aufgabe ist es offensichtlich nicht geeignet. - Es ist nicht möglich, „vollständig komprimierter RAM", da das System für den Betrieb eine bestimmte Anzahl von Nicht-Swap-Seiten im RAM benötigt.
Persönliche Meinungen und Anekdoten:
- Die Hauptverbesserung von zswap in Bezug auf Festplattenschreibvorgänge ist nicht die Tatsache, dass es die Seiten komprimiert, sondern die Tatsache, dass es über ein eigenes Puffer- und Caching-System verfügt, das den Seitencache reduziert und effektiv mehr anonyme Seiten (in komprimierter Form) im RAM speichert. (Basierend auf meiner subjektiven Erfahrung bei der täglichen Verwendung von Linux verhält sich jedoch ein System mit Swap und
zswapden Standardwerten vonswappinessundmax_pool_percentimmer besser als mit jedem beliebigenswappinessWert und ohnezswapoderzswapmit hohen Werten vonmax_pool_percent.) - Niedrige
swappinessWerte scheinen das Systemverhalten zu verbessern, bis die verbleibende Seitencachemenge so gering wird, dass das System aufgrund übermäßiger Festplattenlesevorgänge unbrauchbar wird. Ähnlich verhält es sich mit zu hohen Wertenmax_pool_percent. - Verwenden Sie entweder ausschließlich
zramSwap und begrenzen Sie die Menge der anonymen Seiten, die Sie im Speicher halten müssen, oder verwenden Sie festplattengestützten Swap mitzswapungefähren Standardwerten fürswappinessundmax_pool_percent.
EDIT: Um die Feinheiten Ihrer Frage zu beantworten, könnte ich in Zukunft herausfinden, wie sich der zsmallocin verwendete Allocator in zramBezug auf die Komprimierung im Vergleich zu dem zbudin verwendeten Allocator zswapschlägt. Das werde ich jedoch nicht tun, sondern nur auf Dinge hinweisen, nach denen Sie in Dokumenten/im Internet suchen können.
BEARBEITEN 2:
echo "zsmalloc" > /sys/module/zswap/parameters/zpoolschaltet den Allocator von zswap von zbudauf um zsmalloc. Wenn ich mit meinem Test-Fixture für die obigen Experimente fortfahre und zrammit zswap+ vergleiche zsmalloc, scheint es, dass, solange der benötigte Swap-Speicher der gleiche ist wie bei einem zramSwap oder bei zswap's , die Menge an Lese- und Schreibvorgängen auf der Festplatte bei beiden sehr ähnlich ist. Meiner persönlichen, auf den Fakten basierenden Meinung nach ist es am besten, nur zu verwenden max_pool_percent, solange die zrambenötigte Swap-Menge kleiner ist als die Menge an Swap, die ich mir tatsächlich leisten kann, im RAM zu behalten ; und wenn ich mehr Swap brauche, als ich tatsächlich im Speicher behalten kann, ist es am besten, entweder meine Arbeitslast zu ändern, um dies zu vermeiden, oder Swap zu deaktivieren und mit zu verwenden und auf das Äquivalent dessen einzustellen, was zram zuvor an Speicher belegte (Größe von * Komprimierungsverhältnis). Derzeit habe ich jedoch keine Zeit, diese zusätzlichen Tests ordentlich aufzuschreiben.zramzramzramzswapzsmallocmax_pool_percentzram