„Auswirkung der mkinitcpio-Kompression“
Falls jemandem der Titel dieses Post bekannt vorkommen sollte: Das ist Absicht. Ein gewisser [ENC]BladeXP hatte Ende 2016 bereits einen Artikel zu dieser Thematik geschrieben, und ich wollte das Experiment mal auf einem aktuellen System wiederholen. Allerdings mit einer kleinen Ergänzung: Ich habe mir auch die Zeiten für die Dekompression angesehen.
Verwendet wurde hierfür ein System mit einer NVMe SSD, einem Intel Core i7-8550U, sowie 16GB RAM.
Erzeugen der Ramdisk + Kompression
Nach jedem Kernelupdate muss unter Archlinux mit Hilfe des Tools mkinitcpio eine neue Ramdisk erzeugt werden, welche der Kernel zum Booten benötigt.
In der Tabelle befindet sich dafür jeweils die Angabe des Kompressionsalgorithmus, die Größe der Fallback- und der Standard-Ramdisk, sowie die dafür benötigte Zeit. Der Prozentwert setzt lediglich die erzeugte Dateigröße in Relation zu einer unkomprimierten Ramdisk.
| Algorithmus | Fallback (MB) | Standard (MB) | Zeit (s) | Prozent (%) |
|---|---|---|---|---|
| cat (none) | 127 | 66 | 12,9 | 100,0 |
| gzip | 39 | 22 | 22,0 | 31,6 |
| bzip2 | 37 | 21 | 26,6 | 30,1 |
| lzma | 27 | 15 | 122,9 | 21,8 |
| xz | 27 | 15 | 122,6 | 21,8 |
| lzop | 55 | 31 | 13,4 | 44,6 |
| lz4 | 58 | 31 | 13,4 | 46,1 |
| zstd | 38 | 21 | 13,4 | 30,6 |
cat (none)
Erzeugung der Ramdisk ohne Kompression. Geht zwar schnell, erzeugt aber auch die größten Dateien. Einziger Nachteil ist der relativ hohe Platzverbrauch.
gzip, bzip2
Die beiden etwas älteren Kompressionsformate erzeugen zwar bereits relativ kleine Dateien, brauchen dafür aber auch grob die doppelte Zeit. Nicht zu empfehlen, zumal die Dekompression relativ langsam ist.
lzma, xz
Sowohl lzma als auch xz erzeugen sehr kleine Dateien, brauchen dafür aber auch gut die zehnfache Zeit. Für gewisse Szenarien mag das Sinn ergeben, hier allerdings nicht.
lzop, lz4, zstd
Die drei Verfahren erzeugen mit kaum wahrnehmbaren Overhead (gerade mal 0,5s im Vergleich zu cat) relativ kleine Dateien, wobei zstd auf eine ähnliche Kompressionsrate wie gzip bzw. bzip2 kommt. Leider ist zstd noch nicht fester Bestandteil des Kernels, und ein Booten einer mit zstd komprimierten Ramdisk daher nicht so einfach möglich. Auch wenn lz4 minimal größere Dateien als lzop erzeugt rate ich zu lz4, da die Dekompressionsgeschwindigkeit (wie man gleich sehen wird) bei lz4 wesentlich höher ist.
Lesen der Ramdisk + Dekompression
Die Dekompressionszeit zu messen war leider nicht ganz so einfach. Letztlich habe ich mich dafür entschieden Werte zu nehmen, die ich aus diversen Quellen zusammengetragen, und einer Plausabilitätsprüfung unterzogen habe. Außerdem ist die Dekompression alleine nicht entscheidend für den Bootvorgang, sondern muss auch in Relation zur Lesegeschwindigkeit des Speichermediums gesehen werden.
In der folgenden Tabelle habe ich meine NVMe SSD als Referenz genommen, welche lesend ca. 1,5GB/s schafft.
| Algorithmus | Größe (MB) | Lesen (s) | Dekompression (MB/s) | Zeit (s) | Gesamt (s) | Prozent (%) |
|---|---|---|---|---|---|---|
| cat (none) | 66 | 0,044 | – | – | 0,044 | 100,0 |
| gzip | 22 | 0,015 | 684 | 0,032 | 0,047 | 106,4 |
| bzip2 | 21 | 0,014 | 171 | 0,123 | 0,137 | 310,9 |
| lzma | 15 | 0,010 | 335 | 0,045 | 0,055 | 124,5 |
| xz | 15 | 0,010 | 308 | 0,049 | 0,059 | 133,4 |
| lzop | 31 | 0,021 | 950 | 0,033 | 0,053 | 121,1 |
| lz4 | 31 | 0,021 | 2000 | 0,016 | 0,036 | 82,2 |
| zstd | 21 | 0,014 | 1600 | 0,013 | 0,027 | 61,6 |
Wie man sehen kann ist der Lesevorgang plus die Zeit, welche die Dekompression benötigt, nur bei Einsatz von lz4 oder zstd unter der Zeit, die eine unkomprimierte Ramdisk benötigt. Bei sehr schnellen Speichermedien ist es also fraglich, ob man überhaupt eine Kompression anwenden sollte. Der einzige Vorteil sind die reduzierte Anzahl der Schreib-/Lesezyklen auf das Speichermedium, im Bootvorgang selbst macht es aber keinen Unterschied mehr. Zumal wir hier von Zeit im Bereich weniger Millisekunden reden.
Spannender wird es, wenn man ein etwas langsameres Speichermedium verwendet. Als Beispiel eine SATA-3 SSD welche "nur" 500MB/s lesend schafft:
| Algorithmus | Größe (MB) | Lesen (s) | Dekompression (MB/s) | Zeit (s) | Gesamt (s) | Prozent (%) |
|---|---|---|---|---|---|---|
| cat (none) | 66 | 0,132 | – | – | 0,132 | 100,0 |
| gzip | 22 | 0,044 | 684 | 0,089 | 0,076 | 57,7 |
| bzip2 | 21 | 0,042 | 171 | 0,339 | 0,165 | 124,9 |
| lzma | 15 | 0,030 | 335 | 0,125 | 0,075 | 56,6 |
| xz | 15 | 0,030 | 308 | 0,136 | 0,079 | 59,6 |
| lzop | 31 | 0,062 | 950 | 0,091 | 0,095 | 71,7 |
| lz4 | 31 | 0,062 | 2000 | 0,045 | 0,078 | 58,7 |
| zstd | 21 | 0,042 | 1600 | 0,037 | 0,055 | 41,8 |
Auch hier ist zstd wieder klar führend, gefolgt von lz4 (gzip, lzma und xz fallen aufgrund der geringen Kompressionsgeschwindigkeit bei der Erzeugung weg). Lzo ist auch nicht wirklich schlecht, aber es ist doch ein deutlicher Unterschied gegenüber lz4 erkennbar. Und bzip2 ist für heutige Anwendungsfälle einfach nicht mehr geeignet.
Fazit
Lz4 ist das Mittel der Wahl. Der Algorithmus bietet, unter Berücksichtigung des Speichermediums, der Kompressionszeit/-rate, sowie der Dekompressiongeschwindigkeit, im Moment das beste Verhältnis. Zstd wird wohl der bessere Nachfolger, ist aber zur Zeit noch nicht im Kernel enthalten.
Es bleibt allerdings fraglich, ob bei Speichermedien >500MB/s die Kompression überhaupt noch Sinn ergibt. Die Werte sind jetzt schon kaum mess- geschweige denn wahrnehmbar.