DS415+ Performance-Einbusse nach wechsel auf btrfs

[latti]

Weil ich in meinem 4-Bay System DS415+ zwei neue Festplatten eingebaut habe und nicht zweimal die aufwändige Reparatur durchlaufen lassen wollte, entschied ich mich alles Daten extern zu sichern und das System komplett neu aufzusetzen.

Von ursprünglich 2*WD Red 3 TB und zwei kleineren Platten, sind es nun nach dem Wechsel 4*WD Red 3TB.

Da sowieso alles neu gemacht wird, entschied ich mich auch gleich für das btrfs Dateisystem.

Nun, nach langen Backups und zurückspielen bemerkte ich, dass das System merklich weniger perfomant ist. Allfällige Indexierungen und Datenträger Checks, sind bereits durchgelaufen und komme somit als Übeltäter nicht mehr in Frage... Habt ihr ähnliche Erfahrungen gemacht nach einem Wechsel auf btrfs?

Im Nachhinein denke ich, dass btrfs nicht geeignet ist für meinen Anwendungsfall:

- Plex Server mit vielen Files und immer wieder etwas Transkodieren für Clients.
- Time Machine Speicherziel

Vorallem vermute ich, dass btrfs wertvolle CPU Performance wegfrisst, wenn ich diese für "on-the-fly" Transkodierung benötige.

Bevor ich nun die gesamte Arbeit mit Backup und Rückspeisung wieder starte, wollte ich trotzdem noch rasch hier in die Runde fragen.

 

[bitrot]

Ist das nur 'gefühlt' so oder auch messbar, z.B. hat sich die Übertragungsrate von File Transfers verringert, dauert der Index Aufbau länger, ist das Transcoding langsamer usw.

 

[geimist]

Kann ich bestätigen. Allerdings hatte ich auf meiner DS716+ keine erhöhte CPU-Auslastung. Wenn, dann war das I/O-Warten signifikant erhöht. Für mich war der Unterschied zu Ext4 zu heftig. Nach einem Volumen-Crash während einer Kopieraktion bin ich wieder zurück auf Ext4.

(die SnapShots vermisse ich … dafür ist das System wieder schnell)

Ist das nur 'gefühlt' so oder auch messbar, z.B. hat sich die Übertragungsrate von File Transfers verringert, dauert der Index Aufbau länger, ist das Transcoding langsamer usw.

Ich hatte das schon mal an anderer Stelle geschrieben. Ein Bespiel (genaue Werte weiß ich nicht mehr):
Wenn ich in PIWIK ein Widget neulade, so ist die HDD mit Btrfs erst einmal 20-40 Sekunden mit Lesezugriffen beschäftig (sie rodelt vor sich hin). Unter Ext4 ist das in 3-5 Sekunden erledigt. Und das war nicht nur gelegentlich, sondern grundsätzlich so.
Man hat es an jeder Ecke im System gemerkt (mangelnde Schwuppdizität).

 

[bitrot]

Ok, das klingt ziemlich übel. Bisherigen Reviews nach zu urteilen soll BTRFS sich ja angeblich nicht so stark auf die Performance auswirken, aber da werden meist nur Datentransfers gemessen, im besten Fall noch verschlüsselt. Dennoch müsste das zumindest bei dem Transfer von vielen kleinen Dateien auffallen.

Wahrscheinlich muss BTRFS bei Synology einfach noch ein paar Jahre reifen. Die fehlende automatische Korrektur bei der Implementierung von Synology derzeit macht mich jetzt auch nicht unbedingt heiß drauf. In ein paar Jahren könnten dann günstige SSDs auch das Problem mit den kleinen Dateien bzw. random Lesezugriffen lösen...

 

[raymond]

Und BTRFS wurde zuerst bei den High-End NASes von Synology eingeführt...war es nicht mal so, dass die Privatkunden zuerst Beta-Tester spielen und dann die Erkenntnisse in Profiprodukte übergeben (z.B. Fedora und RHEL)?

Synology nerven würde ich sagen...sollen den letzten LTS Linux Kernel und btrfs-progs nehmen, dann läuft das schon gut.

Schön wäre es, wenn mehrere Leute einen Benchmarkvergleich auf der selben NAS mit der selben DSM bei demselben Test Synology zuschicken können, damit die das auch verstehen... Mit Linux Kernel 3.x wird das auch nix mit Performance bei BTRFS.

 

[latti]

Wenn ich in PIWIK ein Widget neulade, so ist die HDD mit Btrfs erst einmal 20-40 Sekunden mit Lesezugriffen beschäftig (sie rodelt vor sich hin). Unter Ext4 ist das in 3-5 Sekunden erledigt. Und das war nicht nur gelegentlich, sondern grundsätzlich so.
Man hat es an jeder Ecke im System gemerkt (mangelnde Schwuppdizität).

Gemessen habe ich leider nichts, aber es wirklich so, dass die Schwuppizität merklich abgenommen hat.

Was geimist bei PIWIK beschreibt merke ich markant im Plex Server. Alles dauert ewigs, was zuvor auch nur wenige Sekunden dauerte. Auch Aktionen in der FileStation sind weniger fix. Ebenfalls wenn ich vom Rechner aus mit dem Finder etwas lösche/kopiere.

Klingt also tatsächlich danach, dass ich das ganze nochmals neu aufsetzen werde, zumal ich die Vorteile von btrfs ja eigentlich nicht benötige in meinem Setup (Snapshots...). Schad insgesamt, da hätte ich mich vorher wohl besser einlesen müssen bzw. hätte Synology wirklich nur die stärksten Geräte mit der btrfs Möglichkeit ausstatten sollen.

 

[heavygale]

Lass mal noch eine Defragmentierung laufen - evtl. hilft das ja ein wenig, wäre interessant zu wissen.
Ich habe jedenfalls keine Probleme mit meinem BTRFS, beim Daten schieben bekomme ich das Gigabit ausgelastet - evtl. nutze ich aber auch nicht so viele kleine Dateien wie ihr und für Time Machine ist mir die Geschwindigkeit quasi egal.

 

[latti]

Nach meinem Wissen musste man zumindest bei EXT4 nicht defragmentieren (und). Nach kurzer Recherche scheint dies bei btrfs auch nicht nötig zu sein. Zudem wurden ja alle Daten erst frisch auf die Platten geschrieben, auch wüsste ich nicht wie ich defragmentieren könnte. Hast du das denn schon mal machen können?

Trotzdem vermute ich, dass eine Defragmentierung nicht so viel bewirken könnte, dass ich wieder zu meiner vorherigen System-Performance kommen könnte

 

[heavygale]

Die Defragmentierung ist im DSM auch nur für BTRFS verfügbar:
Speicher-Manager -> Volume -> Verwalten -> Dateisystem-Defragmentierung starten -> warten

 

[raymond]

Defragmentieren...WTF:

https://de.wikipedia.org/wiki/Btrfs

Dateisystemüberprüfung und Defragmentierung während des Betriebs

 

[latti]

Danke heavygale für die Info, wo man die Defragmentierung starten kann.

So wie ich das nun nach raymonds Post verstehe, besteht bei EXT4 wie auch btrfs eine Hintergrundfunktion, welche während dem Betrieb kontinuierlich defragmentieren sollte. Will man nun diese Funktion erzwingen, kann man dies über den Speichermanager machen.

Jedenfalls hatte ich bisher nie defragmentiert und die DS415+ lief vor btrfs trotzdem wie am Schnürchen.

 

[heavygale]

Wie dem auch sei, für BTRFS wird die Funktion angeboten und es auszuprobieren kann ja nicht schaden, bevor du erneut alles neu aufsetzt. Mehr wollte ich damit nicht sagen.
Ich habe die Defragmentierung bereits mehrfach ausgeführt und kann sagen, dass sie beim ersten Mal mit Abstand am längsten lief. Ich bin somit nicht davon überzeug, dass das im Hintergrund ohnehin automatisch läuft.

 

[latti]

Nene, du hast mich wohl falsch verstanden. Bin dir dankbar für den Tipp und wusste nichts von dieser Funktion. Jedoch empfinde ich es als schade, dass man sich bei einem neuen Dateisystem wieder um solche Dinge kümmern muss.

Jedenfalls habe ich nach der ganzen Backup-Geschichte die Defragmentierung ausgeführt auf meinen knapp 6TB Daten. Das ganze dauerte etwa 10 Minuten. Jedoch war Plex immer noch nicht flüssiger danach. Die Schwuppizität fehlte auch sonst. Natürlich wieder unter dem Vorbehalt, dass ich nicht gemessen habe.

In etwa 12 Stunden sollte alles wieder bereit sein unter EXT4 und dann werde ich wieder berichten.

Grüsse

Latti

 

[Fusion]

Und, was ist drauß geworden?

 

[raymond]

Kontaktiert auf jeden Fall alle Synology. Meiner Meinung nach haben die es ungenügend getestet und implementiert.

 

[latti]

Hej Fusion

Sorry, hab einerseits den Thread vergessen und andererseits deine Frage erst gerade gesehen.

Mittlerweile habe ich den Wechsel zurück auf EXT4 abgeschlossen und die gefühlte (nicht gemessene) Schwuppizität ist zurück. Über die Gründe der tiefen Performance meiner 415+ unter btrfs kann ich nur Vermutungen anstellen... Denke aber, dass die Performance der Box für meine Anwendungen unter btrfs einfach nicht ausreicht bzw. nicht an jene unter EXT4 herankommt.

 

[Fusion]

Ich hab inzwischen auch mal ein paar Messungen gemacht.
Grundsätzlich habe ich zum Schreiben mit
dd if=/dev/zero of=/volumeX/Freigabe/testfile bs=Y count=1000 [oflag=...]
und lesen mit
dd of=/dev/null if=/volumeX/Freigabe/testfile bs=Y count=1000 [oflag=...]
gearbeitet.
Zudem habe ich noch oflags direct, sync und dsync probiert.
Für die IO-Tests habe ich die Blocksize auf 512 (Byte) und für die Durchsatztests auf 1M (Mebibyte) gesetzt.

https://www.thomas-krenn.com/de/wiki/Linux_I/O_Performance_Tests_mit_dd
https://www.thomas-krenn.com/de/wiki/Dd_mit_direct_oder_synchronized_I/O

Getestet von einem Linux Client aus mit einem CIFS mount.
Achtung: Wenn man z.B. in Nautilus den GVFS mount benutzt sinken die Werte auf weniger als die Hälfte.
Alle Volumes sind Basis Volumes, entweder mit ext4 oder btrfs.
Sowohl mit unverschlüsselten (plain) wie auch verschlüsselten (enc) Gemeinsamen Ordnern.
SSD ist eine Samsung 850 Pro
HDD sind WD Red 6TB

IO-Test (1000 Anfragen, nur auf unverschlüsselte Gemeinsame Ordner getestet)
ext4+hdd und btrfs+ssd brauchen ca. 11ms bzw 13ms pro Anfrage
btrfs+hdd braucht etwa 25ms pro Anfrage.

Durchsatz-Test (1GB schreiben mit Blocksize 1M(B), Blocksize 1G hat keine Verbesserung gebracht)
Lesend kam ich in allen Fällen auf 117MB/s, also Engstelle GBit-Ethernet.

Schreibend (direkt auf der DS im Terminal)
52MB/s (36MB/s enc) auf btrfs+ssd,
28MB/s (20MB/s enc) auf btrfs+hdd,
44MB/s (48MB/s enc) auf ext4+hdd.
Ohne dsync komme ich etwa auf 105MB/s. Vergleichbar mit den Werten weiter unten.
Allerdings treten dann auch Verfälschungen wegen den Write Caches auf, so dass auch mal 800MB/s zu Buche schlugen.

Schreibend (vom Linux Client aus)
95-110MB/s für alle 3 Kombis (btrfs+sdd, btrfs+hdd, ext4+hdd), wobei btrfs+hdd eher an der unteren Grenze und ext4+hdd eher an der oberen Grenze liegt.
Bei verschlüsselten Ordnern sind es noch
56MB/s (btrfs+sdd),
50MB/s (btrfs+hdd),
68MB/s (ext4+hdd).

Die Kombi ext4+ssd fehlt mir noch, aber von den Werten würde ich fast schätzen, dass es die schnellste Kombi in beiden Disziplinen werden wird.
Bei IO ist die ext4+hdd so schnell wie btrfs+ssd.
Beim Durchsatz sind alle gleich schnell beim Schreiben auf CIFS mit unverschlüsselten Ordnern. Bei verschlüsselten hat auch ext4+hdd die Nase vorne.
Einzig wenn ich den Test direkt im Terminal auf der DS mache liegt die
btrfs+ssd beim Schreiben unverschlüsselt vorne, verschlüsselt ist die ext4+hdd wieder vorne.

Welche Schlüsse ich jetzt für meine Bestückung (SSD+3HDD oder 4HDD) ziehe bin ich noch am brüten.
Will ich btrfs wegen der Dateisystem-Features, sollte ich wohl die SSD verbauen.
Hinsichtlich Plex, Datenbanken, etc. scheint allerdings eine HDD mit ext4 gleich gut geeignet und es wäre noch 5TB mehr Speicher verfügbar.
Auf den 6TB HDD genehmigt sich btrfs satte 175GB mehr für die Verwaltung (im vgl. mit ext4), die dann vermutlich fast komplett für Nutzdaten fehlen.
Immerhin schon mehr als 500GB bei 3 Basis-Volumes.
Snapshots und Konsorten wären schon toll, aber ob es der Kompromiss / Geschwindigkeit wert ist... ich weiß noch nicht.

P.S. Das setup ist vermutlich nicht optimal hinsichtlich Caches und anderen Zahlenverbieger, weil ich ja nur Nullen schreibe, aber ich wollte jetzt halt einfach mal ein paar Zahlen haben...

 

[Hafer]

Vor dem Umstieg habe ich nichts gemessen und nach dem Umstieg nichts gemerkt.
Allerdings habe ich die 3*2TB meiner DS415+ mit neuer DSM-Version auf btrfs gehoben, sobald das möglich war (ich glaube 6.0beta) - dabei hat sich soviel geändert, dass eine Messung ohnehin Blödsinn gewesen wäre.

Persönliches Fazit: btrfs ist da und stört nicht.

 

[linuxdep]

ich überlege, wenn ich eine neue DS aufsetze, ob ich btrfs nutzen sollte oder nicht, so ganz ausgereift ist brtfs ja noch immer nicht. Wie ist euer Fazit mittlerweile dazu?

Mehr Vorteile als zu erwartende Nachteile für Btrfs?

 

[Hafer]

Mein Fazit aus #18 hat für mich weiterhin Bestand. Keine Störungen bisher.