Hohe Prozessorauslastung bei ZFS Encryption

[andy_m4]

zweitweiser 93% Auslasung auf 3 CPU Kernen

Wie zeitweise war denn die Auslastung? Eher so mal sporadischer Peak oder durchaus immer in der Größenordnung?
Was vielleicht auch noch ganz interessant zu wissen wäre, ob Du sonstige Dinge wie Deduplication und/oder Kompression nutzt. Und was denn so zfs get encryption mypool/myencrypteddataset sagt.

Textausgaben übrigens gerne als Text und nicht als Screenshot.

 

[polyphase]

Der Peak auf allen 3 Cores wird so 1-2 Sekunden angezeigt, tritt aber nur mit aktiver Verschlüsselung auf.

Hier die Ausgabe (Textausgaben kann ich nicht kopieren, warum auch immer):

Hier der Pool:


Hier das verschlüsselte Dataset:


Anbei die Auslastung:

 

[polyphase]

Edit:
Ich habe noch eine Sache entdeckt, die ist aber unabhängig von TrueNAS bzw. ZFS.
Das tritt ab und zu auch bei meiner Synology auf:

Und zwar wenn ich Dateien von meinem PC auf das NAS (SMB Share) kopiere, bekomme ich eine völlig falsche Geschwindigkeitsangabe:

Ist ne verdammt schnelle 1Gbit Verbindung 🤣

 

[Linuxfreakgraz]

(Textausgaben kann ich nicht kopieren, warum auch immer)

Probier mal Strg+Shift+C

 

[polyphase]

Werde ich morgen Mal ausprobieren

 

[andy_m4]

Weißt Du was mein großes Problem bei der Sache ist? Ich hab keine gute Idee wie man nachgucken kann, ob AES-NI in ZFS benutzt wird (vielleicht hat hier ja jemand anders ne Idee dazu). Den einzigen Ansatz den ich hätte ist halt stumpf im OpenZFS-Quelltext ein logging reinzupatchen das ne Nachricht rausschickt, wenn AES-NI benutzt wird.
Das ist aber kein völlig trivialer Ansatz. Den muss man sich zumindest zutrauen. :-)

Was sonst dann halt bleibt ist von außen draufzugucken und dann seine Schlüsse draus zu ziehen.
Dummerweise gibts auch bei benutzten AES-NI einen Impact auf den Datendurchsatz und auch auf den CPU Load.
Ich hab aber leider keine Erfahrung ZFS und CPUs aus der Klasse des Celeron J4115
Spontan würde ich sagen, das die Prozessorauslastung zu weit noch oben geht. Kann aber auch gut sein, das sie für eine solche CPUs sogar noch halbwegs im Rahmen des Normalen liegt.

Was mir übrigens bei Deinem htop aufgefallen ist, das Samba (/usr/sbin/smbd) viel CPU-Zeit in Anspruch nimmt. Das verfälscht natürlich die Messungen. Ich weiß jetzt nicht, ob Du Deinen Test übers Netzlaufwerk gemacht hast oder so. Falls ja: Mach das nicht. Mach den lieber direkt auf der True Scale Maschine. Zum Beispiel mit sowas wie dd so a-la
dd if=/dev/zero of=/path/to/testfile bs=10M count=1000

Statt mit htop drauf zu gucken kann man auch sowas wie perf nehmen. Da kriegt man dann ne differenzierte Ausgabe die auch in-kernel-Aufrufe aufschlüsselt:
perf top
(ich hab keine Ahnung ob perf bei TrueNAS Scale schon drauf ist; aber soweit ich weiß ist das ein angepasstes Debian ; dann könnte apt install linux-perf funktionieren)

 

[polyphase]

Ja, das war über das Share. Ich werde es morgen Mal direkt auf der Maschine ausprobieren.

Erstmal danke für deine Hilfe 👍

 

[polyphase]

@andy_m4
Also:
perf top geht nur über die Shell im Webinterface, dort kann ich keinen Text kopieren.
Über SSH lässt es sich garnicht erst starten.

Ich habe deinen Befehl etwas abgeändert, da ZFS durch die komprimierung bei "/dev/zero" falsche Geschwindikgeitswerte bringt, hab ich gelesen

dd if=/dev/urandom of=/mnt/store1/dataset2/zeszfile1 bs=10M count=1000

Das ergibt folgendes Ergebnis:

709+0 records in
709+0 records out
7434403840 bytes (7.4 GB, 6.9 GiB) copied, 83.33 s, 89.2 MB/s

Bei folgender Auslastun (leider nur screenshot)



Jetzt habe ich irgendwo gelesen, das TrueNAS Scale eine Bug hat, sodass AES-NI auf Atom CPUs nicht richtig funktionieren soll. Wenn ich die Seite wieder finde, verlinke ich es hier.

Ich werde das ganze nochmal unter TrueNAS Core und Ubuntu Server testen, die Tage.




Und hier die Messungen ohne Verschlüsselung:

339+0 records in
339+0 records out
3554672640 bytes (3.6 GB, 3.3 GiB) copied, 33.222 s, 107 MB/s

 

[andy_m4]

Ich habe deinen Befehl etwas abgeändert, da ZFS durch die komprimierung bei "/dev/zero" falsche Geschwindikgeitswerte bringt

Ja. Eine bloße Folge von Nullen lässt sich natürlich exzellent wegkomprimieren.

Das ergibt folgendes Ergebnis:

Wäre ja vor allem der Unterschied im Vergleich zu "unverschlüsselt" interessant.

Bei folgender Auslastun

Dadurch das die Funktion aes_aesni_encrypt aufgerufen wird, kann man schon davon ausgehen das AES-NI benutzt wird. Weil das geht dann durch auf den bereits schon oben angesprochenen Intel-Assembler-Code.

Jetzt habe ich irgendwo gelesen, das TrueNAS Scale eine Bug hat, sodass AES-NI auf Atom CPUs nicht richtig funktionieren soll.

Kann natürlich sein. Wobei es dann potentiell auch andere Encryption-Routinen betrifft wie die von OpenSSL. Wenn man da also bei TrueNAS nix zu findet, könnte man auch noch mal in der Richtung recherchieren.
Möglicherweise gibts ja da irgendwo auch schon ein Patch.

Wenns ein Problem in der CPU selbst ist, dann hilft evtl. auch ein Microcode-Update. Auch in die Richtung könnte man mal schauen und probieren.

 

[polyphase]

@andy_m4
Die zweite Messung ist ohne Verschlüsselung 😉

Ergänzung (14. November 2022)

Update:
Unter TrueNAS Core ist die CPU Auslastung auf dem Verschlüsslten Share viel niedriger!
Leider funktioniert hier der Befehl "perf top" nicht:

Daher nur die Ausgabe von htop:




Ausgabe vom dd Befehl auf dem verschlüsselten dataset:

724+0 records in
724+0 records out
7591690240 bytes transferred in 56.700652 secs (133890704 bytes/sec)

Das müssten doch 133Mbyte/s sein oder?


ohh.... das sieht gut aus 😀

Das "NAS" zieht jetzt auch unter Last 5W weniger aus der Steckdose!

 

[andy_m4]

Leider funktioniert hier der Befehl "perf top" nicht

Nein. Der ist Linux-exklusiv.
Bei TrueNAS Core musst Du das FreeBSD-Pendant nutzen. Du könntest theoretisch via DTrace drauf gucken. Oder halt ganz simpel&stupid mit truss. Da fallen zwar viele Daten an, aber das kann man durchsuchen lassen, ob man den o.g. Aufruf findet.

Das müssten doch 133Mbyte/s sein oder?

Naja. 1kb sind ja nicht 1000 Byte sondern 1024, aber so Größenordnungsmäßig kommt das hin.

Jedenfalls wenn für Dich TrueNAS Core gut funktioniert, dann kann man das Problem doch als gelöst betrachten, oder?

 

[polyphase]

Bis jetzt ja 😅
Muss nur überlegen wie ich das mit Docker mache. Wollte das eigentlich aus der VM vom Mini Server auf das NAS umziehen.

Blöde Frage:
Ist es möglich den Pool zuerst mit nur einer Festplatte zur erstellen und die zweite fürs Mirror dann nachträglich hinzuzufügen?

Sonst müsste ich eine 12TB Platte als "Zwischenspeicher" anschaffen, da ich aktuell nur zwei Platten in der DS216+ am laufen habe und an die Backup Platte will ich eigentlich nicht Ran.

 

[andy_m4]

Muss nur überlegen wie ich das mit Docker mache.

Ja. Docker ist ein Problem (gibt zwar Projekte die sich dem annehmen, aber die sind noch nicht production-ready). Man kann das natürlich mit VMs abbilden (also man macht ne Linux-VM und wirft da die Docker-Container rein), aber wirklich schön ist das nicht.
Kommt auch ein bisschen drauf an, was für Anwendungen das sind. Evtl. macht es ja Sinn die "zu Fuß" zu installieren. Dann noch in Jails wenn man ne Separation hinkriegen will. Denn die Primitives für Container hat FreeBSD ja alle.
Es gibt inzwischen auch Docker-vergleichbare Alternativen. So Potluck und Co, wo Du auch vorgefertigte Appliances kriegen kannst.

Ist es möglich den Pool zuerst mit nur einer Festplatte zur erstellen und die zweite fürs Mirror dann nachträglich hinzuzufügen?

Im Prinzip ja, aber .... :-)
Das Grundproblem bei RAIDs ist, das die Platten mindestens so groß sein müssen wie die Bestandsplatten.
Klingt erst mal trivial ist es aber in der Praxis häufig nicht. Man hat irgendwie schon ne 2GB Bestandsplatte und überlegt sich jetzt einfach ne 2GB-Platte dazu zu kaufen. Den die Angabe von 2GB ist jetzt keine fest definierte Angabe. Das sind Schwankungen drin. Je nachdem wie der Hersteller das rechnet aber auch innerhalb eines Herstellers schwankt das. Und dann stehtman plötzlich mit seiner 2GB Platte da und kann die nicht zum RAID hinzufügen, weil die 10 MB kleiner ist das die, die schon drin ist.

Deswegen ist es ne gute Idee beim Anlegen eines Pools bei einer Platte nicht the whole disk zu nehmen, sondern zu Partitionieren und die Partition quasi ein bisschen kleiner zu machen. Damit verschenkt man zwar ein bisschen Platz, erspart sich aber später Ärger wenn man ne Platte hinzufügen will.

Sonst müsste ich eine 12TB Platte als "Zwischenspeicher" anschaffen

Evtl. lohnt es da auch mal den Datenbestand etwas zu verkleinern. Evtl. kann man ja die ähm ... Filmchensammlung mal ein bissl ausdünnen. :-)

 

[polyphase]

Deswegen ist es ne gute Idee beim Anlegen eines Pools bei einer Platte nicht the whole disk zu nehmen, sondern zu Partitionieren und die Partition quasi ein bisschen kleiner zu machen. Damit verschenkt man zwar ein bisschen Platz, erspart sich aber später Ärger wenn man ne Platte hinzufügen will.

Das hat aber im Grunde nichts damit zu tun ob's man nun mit einer oder zwei Platten startet.

Evtl. lohnt es da auch mal den Datenbestand etwas zu verkleinern. Evtl. kann man ja die ähm ... Filmchensammlung mal ein bissl ausdünnen. :-)

Das hat ja im Grunde nichts damit zu tun, denn dann benötige ich trotzdem eine weitere Platte. Sonst habe ich in der DS sowie dem neuen NAS je nur eine Platte

 

[andy_m4]

Das hat aber im Grunde nichts damit zu tun ob's man nun mit einer oder zwei Platten startet.

Richtig. Das hat damit nix zu tun, kann aber ein Stolperstein sein. Wenn Du also gerade ein Pool aufbaust mit dem Gedanken in die Richtung in 2 Monaten mal ne Platte hinzuzufügen, dann gucke da jetzt schon drauf, als dann in 2 Monaten dumm da zu stehen.
Wenn das schon ein Bestandspool ist, dann ists für solche Überlegungen natürlich schon zu spät. :-)

Das hat ja im Grunde nichts damit zu tun, denn dann benötige ich trotzdem eine weitere Platte.

War jetzt eher so gedacht: Ohne Filmchen kriegt man die Daten auch auf nem Stick zwischengespeichert. :-)

 

[polyphase]

War jetzt eher so gedacht: Ohne Filmchen kriegt man die Daten auch auf nem Stick zwischengespeichert. :-)

Bei mir leider nicht 😉

 

[polyphase]

@andy_m4
Ich hab nochmal ne ganz doofe Frage.
Soweit ich das verstanden habe, ist ZFS die darunter liegende Hardware egal.

Wie wäre es, wenn ich ein Ubuntu Server basierendes System aufbaue und die Platten mit Luks verschlüssel. Dort dann ZFS oben drauf.

Müsste doch funktionieren, ich meine sowas sogar gelesen zu haben 🤔

Vorteil wäre:
Ich hätte ein System mit dem ich mich halbwegs auskenne (Linux). Könnte ZFS nutzen, inkl. funktionierendem AES-NI. Und hätte Docker zur Verfügung, wie ursprünglich geplant 👍

 

[andy_m4]

Soweit ich das verstanden habe, ist ZFS die darunter liegende Hardware egal.

Ähm ja.

Wie wäre es, wenn ich ein Ubuntu Server basierendes System aufbaue und die Platten mit Luks verschlüssel. Dort dann ZFS oben drauf.

Das kann man im Prinzip machen.
Das war auch der Weg den man gegangen ist, bevor man native encryption in ZFS hatte und je nach Sicherheitsbedürfnis macht man das auch heute noch so.

Die Frage wäre aber, tritt unter ubuntu überhaupt der Bug auf? Evtl. ist der ja aus irgendeinem Grund TrueNAS Scale exklusiv.

 

[polyphase]

Hab den Beitrag endlich gefunden:
https://www.truenas.com/community/threads/22-02-release-performance-regressions.99236/#post-687740

Ist wohl ein Bug in OpenZFS selbst.....

 

[andy_m4]

Wofür es ja offenbar nicht mal ein handfesten technischen Grund gibt, weil sonst würde das Problem unter FreeBSD ja genauso auftreten, sondern das letztlich so ne Lizenzgeschichte ist. Und sowas finde ich ja immer besonders nervig.