Ordner-Verschlüsselung nutzt nur 25% der CPU

[sysad]

Ich besitze eine DS1511+, bei der ich im RAID1 (2x3TB Platten) 60-90 MB/s beim Schreiben größerer Dateien erreiche. Nun habe ich für einen Ordner die Verschlüsselung aktiviert, wodurch die Geschwindigkeit natürlich einbricht. Über SMB/AFP komme ich so schreibend nur noch auf ca. 12 MB/s.

Mir war klar, dass die Geschwindigkeit stark einbrechen wird und ich kann im Prinzip auch mit den 12 MB/s leben, wenn das eben das Limit der Hardware ist. Was mich aber sehr wundert ist, dass der Ressourcenmonitor während des Kopiervorgangs für den SMB- bzw. AFP-Prozess konstante 25% CPU-Auslastung anzeigt (alle anderen Prozesse sind unauffällig - es gibt also keinen speziellen Encryption-Prozess). Es gibt keinerlei Schwankung nach oben oder unten - es scheint fast so als würde das System des NAS die CPU-Leistung auf diese 25% beschränken um andere Prozesse nicht zu stören.

Wenn ich mir nun aber den Unterschied zwischen unverschlüsselten Ordnern (75MB/s) und verschlüsselten Ordnern (12MB/s) anschaue, bin ich mir sicher, dass ohne diese künstliche Beschränkung deutlich bessere Datendurchsätze möglich wären. Nachdem ich ohnehin keine anderen Dienste (Webserver, etc.) nutze, bringt es mir gar nichts, wenn 75% der CPU-Leistung ungenutzt bleiben. Viel mehr würde es mich freuen, wenn ich die Geschwindigkeit verdoppeln könnte - was IMO durchaus realistisch ist, wenn meine Vermutung mit den 25% richtig ist. Ich kaufe mir doch kein Gerät mit 1,8 GHz CPU, wenn das System mich davon für meine Hauptanwendung nur einen Bruchteil nutzen lässt.

Könnt Ihr das bei Euch auch beobachten und gibt es eine Möglichkeit diese Beschränkung von 25% auf z.B. 80% (oder 50% - wenn die Encryption-Engine nur einen Core verwenden kann) anzuheben?

 

[amarthius]

Also von Synology gibt es DSen, welche mit einer integrierten Hardwareverschlüsselungseinheit ausgestattet sind. Diese ver- und entschlüsseln schneller als andere NASe. Die DS1511+ besitzt keinen. Deine Werte kommen nah an die von Synology ermitteltenten ran. Daher gehe ich von keinem defekt oder ähnlichem aus.
Siehe hier (Encrypted File 5GB): http://www.synology.com/products/performance.php?lang=enu#tabs-10
Zumal die Atoms recht schwachbrüstig sind.

Falls du detailliertere Informationen willst, kannst du gerne den Support kontaktieren.

 

[itari]

Wie sieht denn die Performance aus, wenn man mehrere Kopiervorgänge auf unterschiedliche verschlüsselte Ordner absetzt? Erhöht sich dabei die Gesamtperformance auf der DS1511+?

Itari

 

[sysad]

Wie sieht denn die Performance aus, wenn man mehrere Kopiervorgänge auf unterschiedliche verschlüsselte Ordner absetzt? Erhöht sich dabei die Gesamtperformance auf der DS1511+?

Gute Idee. Ich habe jetzt 2 Verbindungen auf den gleichen verschlüsselten Ordner erstellt - 1x per AFP und 1x per SMB - und jeweils einen Transfer gestartet. Diese Transfers laufen jetzt mit jeweils ca. 10-11MB/s und mit insgesamt 45%-50% CPU-Auslastung. Ich komme somit also durch 2 gleichzeitige Kopiervorgänge auf über 20MB/s - trotz Verschlüsselung. Auch die Verdoppelung der CPU-Auslastung ist wie erwartet eingetreten.

Meine Theorie ist also richtig. Das Gerät drosselt eine einzelne AFP/SMB Verbindung auf 25% CPU-Auslastung, was der Hauptgrund für den starken Leistungseinbruch bei verschlüsselten Ordnern ist. Würden wenigsten 80-90% der CPU-Leistung zur Verfügung stehen sollten locker 30-35MB/s für einen Schreibvorgang auf einen verschlüsselten Ordner drin sein.

Was nicht geht ist mit dem gleichen User über das gleiche Protokoll zwei Dateien zu schicken. Dann teilen sich die zwei Kopiervorgänge die 25% und laufen nur noch mit jeweils 5MB/s. Das 25% Limit ist also auf das Protokoll gebunden.

Nun wären die Linux Profis gefragt. Wo sitzt dieses 25% Limit und wie hebe ich es auf oder erhöhe es auf z.B. 80%?

Hier ein Auszug der CPU-Auslastung (erstellt mit dem Befehl "top" per Terminalverbindung):

27039 2339 User1 R 13956 1.3 24.7 /usr/syno/sbin/afpd -c 256 -g guest -n NAS:AFPServer
8455 1971 User1 R 18660 1.8 24.6 /usr/syno/sbin/smbd -D
8474 2 root SW 0 0.0 1.6 [flush-253:13]
27649 2 root SW 0 0.0 0.5 [md2_raid1]
324 2 root SW 0 0.0 0.5 [kswapd0]
...

Man sieht, dass afpd 24,7% und smbd 24,6% CPU-Auslastung erzeugen.

Wenn nun ein Kopiervorgang fertig ist, läuft der zweite mit ca. 25% weiter und nutzt nicht die frei gewordene CPU-Leistung:

8455 1971 User1 R 18660 1.8 24.5 /usr/syno/sbin/smbd -D
8474 2 root SW 0 0.0 0.6 [flush-253:13]
27649 2 root SW 0 0.0 0.2 [md2_raid1]
324 2 root SW 0 0.0 0.2 [kswapd0]
...

 

[itari]

Wie sieht es aus, wenn du nicht verschlüsselst? Wird dann auch die Bremse gezogen? Verdoppelt sich der Durchsatz bei 2 unterschiedlichen Protokollen?

Hintergrund: Es kann ja sein, das es gar nicht ums Verschlüsseln geht, sondern dass die jeweiligen Dateiserver (Samba, AFP usw.) an und für sich gedrosselt werden, damit Mediastreams nicht total benachteiligt werden, wenn man mal etwas kopiert ... das würde ja schon Sinn geben

Itari

 

[sysad]

Wie sieht es aus, wenn du nicht verschlüsselst? Wird dann auch die Bremse gezogen? Verdoppelt sich der Durchsatz bei 2 unterschiedlichen Protokollen?

Hintergrund: Es kann ja sein, das es gar nicht ums Verschlüsseln geht, sondern dass die jeweiligen Dateiserver (Samba, AFP usw.) an und für sich gedrosselt werden, damit Mediastreams nicht total benachteiligt werden, wenn man mal etwas kopiert ... das würde ja schon Sinn geben

Das Problem ist, dass ich ohne Verschlüsselung den smbd- oder afpd-Prozess kaum auf 25% hochbringen kann. Ich gehe schon davon aus, dass er dann auch dicht machen würde. Ich habe es jetzt mal mit 6 gleichzeitgen Transfers versucht und damit gerade mal 14-18% CPU-Last auf dem smbd-Prozess erzeugen können. Die Tansfergeschwindigkeit ging dann auf 6x10-15MB/s (Gesamt ca. 65MB/s) zurück. Für deutlich über 25% potentielle CPU-Last (ich müsste die 25% ja deutlich überschreiten um die Drosselung auf 25% nachzuweisen) bräuchte ich sicher 15+ gleichzeitige Transfers, nur gibt das dann die lokale Festplatte meines iMacs kaum her, so dass dann eher aus der Richtung die Leistung einbricht.

Was ich aber testen konnte ist der Transfer über 2 Protokolle ohne verschlüsselten Ordner. Hier die Ergebnisse:

1 File per SMB: stabile 85MB/s - CPU-Last des smbd-Prozesses 9-12%
1 File per SMB + 1 File per AFP: schwankende 2x30-40MB/s - CPU-Last der smbd- und afpd-Prozesse: je 5-8%

Hier kann man also keine Steigerung durch 2 Transfers/Protokolle erzielen - im Gegenteil wird es sogar etwas langsamer als ein einzelner Transfer. Also genau so, wie man es erwarten würde und wie ich es mir auch für verschlüsselte Ordner erwarten würde. Zwei Transfers dürfen nie schneller als ein einzelner sein, wenn nicht irgendwo künstlich gedrosselt wird.

Von daher bleibe ich dabei, dass man einen Transfer (schreibend) auf einen verschlüsselten Ordner auf 30MB/s bringen könnte, wenn man das System so hinbiegt, dass er für den afpd-Prozess (der wohl auch die Verschlüsselung beinhaltet) 80% statt 25% CPU-Leistung nutzt. Nur wie konfiguriert man das bzw. an welcher Stelle hat Synology oder die Linux-Basis die Drosselung der afpd- und smbd-Prozesse implementiert? Ich will meine CPU voll (oder - wenn möglich - zu 80%) für den Fileserver-Part nutzen und nicht 75% für Medienstreaming und andere Dienste freihalten - sowas fällt bei mir nicht gleichzeitig an. Entweder ich kopiere Daten oder ich schaue mir ein Video an. Dass es dabei zu keiner Überschneidung kommt, kann ich gut selbst steuern - gerade wenn der Transfer dafür 2,5x - 3x schneller fertig ist.

 

[Merthos]

Mein Backup mit rsync in einen verschlüsselten Ordner erreicht auch nur 10-12 MB/s. An der Stelle ist kein SMB oder AFP beteiligt, von daher liegt die Drosselung eventuell im eCryptfs?

 

[sysad]

Mein Backup mit rsync in einen verschlüsselten Ordner erreicht auch nur 10-12 MB/s. An der Stelle ist kein SMB oder AFP beteiligt, von daher liegt die Drosselung eventuell im eCryptfs?

Oder es ist eine allgemeine Beschränkung, bei der kein einzelner Prozess über 25% Leistung gehen darf?

Nur an welcher Stelle ist die Beschränkung implementiert? Gibt es hier keine Linux-Profis, die über mögliche Stellen Bescheid wissen, an denen man sowas eingebaut haben könnte? Ich hätte kein Problem damit ein wenig zu testen, nur bräuchte ich halt erst mal einen Ansatzpunkt. "renice" habe ich schon versucht - hat aber nichts gebracht, sofern ich mich nicht vollkommen falsch bei der Ausführung angestellst habe.

Hast Du auch genau die 25% CPU-Auslastung, wenn Du per rsync kopierst?

 

[Merthos]

Das Backup läuft nachts, von daher kann ich das nicht sagen. Ein kurzer Test auf der Kommandozeile (mit mc) ergibt auch 10 Mb/s mit Verschlüsselung vs. 60 Mb/s ohne. Die Last geht in beiden Fällen nicht über 25%.

 

[janus]

Moin,
ich hab gerade mal ein "cat /proc/cpuinfo" laufen lassen. Ist zwar nur eine 1010+, aber ich gehe mal davon aus, dass der Prozessor ähnlich ist...

Jetzt ratet mal, was __4__ * 25% ergeben ;-)

Gruß

Janus
p.s.: Noch ein Tip: Ich glaube hiermit eher nicht, dass die Serverprozesse Threaded arbeiten.

 

[sysad]

Moin,
ich hab gerade mal ein "cat /proc/cpuinfo" laufen lassen. Ist zwar nur eine 1010+, aber ich gehe mal davon aus, dass der Prozessor ähnlich ist...

Jetzt ratet mal, was __4__ * 25% ergeben ;-)

Wenn ich Dich richtig verstehe ist die 25% Anzeige also nicht richtig, sondern resultiert daraus, dass die CPU-Auslastungsanzeige Dualcore und Hyperthreading so darstellt, als hätte man 4 vollwertige CPUs. Tatsächlich ist aber schon bei der 25% Anzeige ein Kern nahezu voll ausgelastet, was also vereinfacht dargestellt (ohne den möglichen kleinen Schub durch Hyperthreading) ca. 50% realer Auslastung entspricht?

Außerdem ergibt sich daraus in Kombination mit meinen Benchmarks, dass die Prozesse nicht in der Lage sind die zwei Kerne der D525 CPU zu nutzen. So lange das der Fall ist, wird man also nie über die 25%-Anzeige (welche eigentlich ca. 50% entspricht) hinaus kommen, und das Potential der Dual-Core-CPU nicht nutzen. Dass eine Dual-Core-CPU eingebaut ist, wirkt sich daher erst dann aus, wenn ein zweiter CPU-lastiger Vorgang auf einem anderen Prozess gleichzeitig anfällt.

Trotzdem könnte man die Geschwindigkeit bei verschlüsselten Ordnern nahezu verdoppeln, wenn man den afpd- und smbd-Prozessen beibringen könnte mit mehreren Kernen umzugehen und somit von der Dual-Core-CPU auch bei einzelnen Transfers zu profitieren. So wie es jetzt umgesetzt ist, arbeitet man quasi leistungstechnisch wie mit einer 1,8GHz Singlecore-CPU und profitiert gerade im Single-User-Heimbereich sehr selten vom zweiten CPU-Kern, da man selbst bei zwei gleichzeitigen Transfers als Einzeluser eher selten über zwei verschiedene Protokolle gehen wird.

Weiß jemand, ob man smbd oder afpd beibringen kann mehrere Kerne zu nutzen? So wie ich jetzt mit Google herausgefunden habe, beschränkt sich das bei Samba per Default wohl tatsächlich darauf, dass ein zweiter User einen eigenen Prozess bekommt, der dann bei Bedarf auf dem zweiten Kern läuft. Also in etwa das was ich mit der Trennung auf AFP und SMB auch herbeigeführt habe. Würden wir (oder Synology) hier einen echten Multicore-Support hinbekommen, würde sich der Durchsatz mit verschlüsselten Ordnern in etwa verdoppeln lassen. Gerade im Zusammenhang mit eine CPU-lastigen Verschlüsselung sollte man 2011 doch eigentlich davon ausgehen, dass auch die tatsächliche CPU-Leistung genutzt werden kann. Sind Linux und die verwendeten Open-Source Bausteine da echt so rückständig oder hat Synology hier bewußt oder unbewußt Potential verschenkt?

 

[itari]

... oder hat Synology hier bewußt oder unbewußt Potential verschenkt?

Frag doch einmal beim Synology-Support nach, ob sich da was machen lässt.

Itari

 

[janus]

Wenn ich Dich richtig verstehe ist die 25% Anzeige also nicht richtig, sondern resultiert daraus, dass die CPU-Auslastungsanzeige Dualcore und Hyperthreading so darstellt, als hätte man 4 vollwertige CPUs. Tatsächlich ist aber schon bei der 25% Anzeige ein Kern nahezu voll ausgelastet, was also vereinfacht dargestellt (ohne den möglichen kleinen Schub durch Hyperthreading) ca. 50% realer Auslastung entspricht?

Also wenn ich das bei bei 4 CPU Kernen richtig sehe, dann (Hyperthreading hies das wohl mal, als die Kerne noch weniger Parallel gearbeitet haben) sind 25% IMHO genau eine CPU, 50% sind dann 2 CPUs usw. Kommt manchmal darauf an, welches Tool man beim Messen benutzt.

Htop aus dem ipkg kann z.B. die Last jedes einzelnen CPU Kerns anzeigen. Was mir im Moment noch fehlt, ist ein Tool, welches auch anzeigen kann, auf welchem Kern ein Prozess gerade läuft.

Außerdem ergibt sich daraus in Kombination mit meinen Benchmarks, dass die Prozesse nicht in der Lage sind die zwei Kerne der D525 CPU zu nutzen. So lange das der Fall ist, wird man also nie über die 25%-Anzeige (welche eigentlich ca. 50% entspricht) hinaus kommen, und das Potential der Dual-Core-CPU nicht nutzen. Dass eine Dual-Core-CPU eingebaut ist, wirkt sich daher erst dann aus, wenn ein zweiter CPU-lastiger Vorgang auf einem anderen Prozess gleichzeitig anfällt.

Würde ich auch so sehen, dass der Serverprozess kein Threading kann. Wobei ich da nicht direkt Synology sagen würde, sondern der Samba bzw. die Server Prozesse scheinen das einfach nicht besser zu können. Die meisten dieser Tools stammen ja auch noch aus einer Zeit, als ein Privatanwender meist keine Multicore Boards eingesetzt hat und alle noch geglaubt haben, dass viele GHz auch mehr Leistung bedeuteten.

Trotzdem könnte man die Geschwindigkeit bei verschlüsselten Ordnern nahezu verdoppeln, wenn man den afpd- und smbd-Prozessen beibringen könnte mit mehreren Kernen umzugehen und somit von der Dual-Core-CPU auch bei einzelnen Transfers zu profitieren. So wie es jetzt umgesetzt ist, arbeitet man quasi leistungstechnisch wie mit einer 1,8GHz Singlecore-CPU und profitiert gerade im Single-User-Heimbereich sehr selten vom zweiten CPU-Kern, da man selbst bei zwei gleichzeitigen Transfers als Einzeluser eher selten über zwei verschiedene Protokolle gehen wird.

Dazu ein Zitat von http://www.samba.org/samba/docs/man/Samba-Developers-Guide/architecture.html#id2556751:
"Multithreading and Samba

People sometimes tout threads as a uniformly good thing. They are very nice in their place but are quite inappropriate for smbd. nmbd is another matter, and multi-threading it would be very nice.

The short version is that smbd is not multithreaded, and alternative servers that take this approach under Unix (such as Syntax, at the time of writing) suffer tremendous performance penalties and are less robust. nmbd is not threaded either, but this is because it is not possible to do it while keeping code consistent and portable across 35 or more platforms. (This drawback also applies to threading smbd.)

The longer versions is that there are very good reasons for not making smbd multi-threaded. Multi-threading would actually make Samba much slower, less scalable, less portable and much less robust. The fact that we use a separate process for each connection is one of Samba's biggest advantages. "

Weiß jemand, ob man smbd oder afpd beibringen kann mehrere Kerne zu nutzen? So wie ich jetzt mit Google herausgefunden habe, beschränkt sich das bei Samba per Default wohl tatsächlich darauf, dass ein zweiter User einen eigenen Prozess bekommt, der dann bei Bedarf auf dem zweiten Kern läuft. Also in etwa das was ich mit der Trennung auf AFP und SMB auch herbeigeführt habe. Würden wir (oder Synology) hier einen echten Multicore-Support hinbekommen, würde sich der Durchsatz mit verschlüsselten Ordnern in etwa verdoppeln lassen. Gerade im Zusammenhang mit eine CPU-lastigen Verschlüsselung sollte man 2011 doch eigentlich davon ausgehen, dass auch die tatsächliche CPU-Leistung genutzt werden kann. Sind Linux und die verwendeten Open-Source Bausteine da echt so rückständig oder hat Synology hier bewußt oder unbewußt Potential verschenkt?

Leider scheint es keine gute Idee zu sein, Netzwerk Filesystem Prozesse in Threads zu verpacken. Deswegen halte ich es für eher unwahrscheinlich, dass Synology da was tun kann. Ich denke im Moment, dass eine Hardware Verschlüssellung die beste Lösung ist.

Gruß

Janus
p.s.: Damit würde ich im Moment keine x86 basierte Synology NAS kaufen, wenn es um Datenverschlüssellung geht.
p.p.s: Ich könnte mir vorstellen, dass eine Threaded Ver bzw. Ent-Schlüssellung auch keine besonders gute Idee ist, wenn es um Blockbasiertes Lesen und Schreiben auf eine Disk geht.

 

[sysad]

p.s.: Damit würde ich im Moment keine x86 basierte Synology NAS kaufen, wenn es um Datenverschlüssellung geht.

Dafür machen die x86-Systeme echt wenig Sinn. Sie sind zwar nicht langsamer, aber trotz höherem Preis und mehr Energiebedarf bei verschlüsselten Ordnern auch nicht wirklich viel schneller als eine Lösung mit Marvell-Chip. Von daher wird für mich x86 nur interessant, wenn 4 Bays nicht ausreichen. Gerade die neue 12-Bay-Lösung könnte hier ganz nett und in der Preisklasse auch konkurrenzlos sein. Bis 4 Bays würde ich zu einer Marvell-Lösung raten - wobei hier dann die Netzteilproblematik der 411j zum Tragen kommt, so dass ich vermutlich sogar zur QNAP Konkurrenz greifen würde.

Die ganzen mitgelieferten Zusatzfeatures, die auch von x86 profitieren würden, finde ich relativ nutzlos, da sie alle sehr beschränkt in ihrer Konfiguration sind (wer will sich z.B. für eine Photo- oder Mediensammlung die Ordner vorschreiben lassen?). Und groß Herumbasteln möchte ich ehrlich gesagt an einem NAS-Betriebssystem auch nicht. Immerhin habe ich das Teil gekauft, weil dort TB-weise Daten von mir abgelegt sind. Deren Sicherheit hat ganz klar Priorität vor irgendwelchen Linux-Basteleien.

p.p.s: Ich könnte mir vorstellen, dass eine Threaded Ver bzw. Ent-Schlüssellung auch keine besonders gute Idee ist, wenn es um Blockbasiertes Lesen und Schreiben auf eine Disk geht.

Truecrypt profitiert z.B. davon, obwohl es dort auch um Verschlüsselung auf Platte geht. Wobei ich mit echten 50% zumindest schon besser als mit den anfangs vermuteten 25% leben kann. Ich habe jetzt z.B. meinen Media-Player mit einem eigenen User ausgestattet und kann so zumindest bei Download+Wiedergabe beide Kerne nutzen, auch wenn das nicht oft vorkommt.

 

[RudiWiesmayr]

Griasseich! Interessante Diskussion...

Kucktihr bitte http://www.synology-wiki.de/index.php/X86-64

lG Rudi