Re: Welches Dateisystem direkt für Hardwareserver?
Martin Steigerwald <martin@lichtvoll.de> wrote:
> Sven Hartge - 07.01.18, 22:17:
>> Stefan Krueger <Shadow_7@gmx.net> wrote:
>>> ich hab hier nen neuen Server 2SSDs und nen RaidController, der aber
>>> auch die Disks direkt durchreichen kann. Unser Monitoringsystem
>>> soll da rauf, ist jedoch relativ Datenbanklastig (PostgreSQL), für
>>> mich stellt sich jetzt die Frage btrfs mit RAID1 und evtl Sub-Vols
>>> (extra für PostgreSQL) oder mach ich nen RAID1 mit dem
>>> RAID-Controller und darauf dann ext4?
>>
>> Ich würde den RAID-Controller wegwerfen bzw. die SSDs durchreichen
>> lassen und direkt RAID1 mit dem Kernel machen. Darauf dann LVM und
>> ext4 oder xfs.
>>
>> Ist einfacher zu verwalten und deutlich performanter als wie via
>> RAID-Kontroller. (Ja, ich habe das gebenchmarkt.)
> Ich vermute, unterschiedliche Hardware-RAID-Controller liefern
> unterschiedliche Ergebnisse.
Ja. Interessanterweise alle schlechter wie SoftRAID via Kernel.
Oder anders ausgedrückt: Um in die Nähe vom SoftRAID zu kommen, brauchte
ich bei den RAID-Controllern im RAID-Modus mehr manuelles Tuning wie
wenn ich die Datenträger einfach stumpf durchgereicht habe.
Interessanterweise wurde es noch grauenhafter, wenn als ich die höheren
RAID-Level getestet habe.
Kurzbeispiel aus den Kopf:
LSI SAS 9750-8i mit 24 Platten (als RAID60), 512MB Cache und BBU.
Schreibleistung: Mit Achen und Krachen 500MByte/s und viel Bitten,
testen und Werte anpassen.
Platten auf JBOD umgestellt, Linux-Kernel 2x12 RAID6 via LVM
zusammegefasst.
Schreibrate out-of-the-box: 1200MByte/s
Seitdem nie wieder Hardware-RAID, wo ich es vermeiden kann.
Plus: Kein Hampeln mehr mit irgendwelchen proprietären
RAID-Kontroller-Tools.
> Ich würde jedoch auch zu SoftRAID 1 tendieren.
>> btrfs würde ich nicht in der Produktion verwenden.
>>
>> Dazu kommt, dass CoW-Dateisysteme unpassend für Datenbank-Systeme sind.
>> Für btrfs wird für Postgres/MySQL/MariaDB dringend empfohlen, das
>> CoW-Feature abzuschalten.
> Auch für SSDs? Copy On Write verringert vor allem bei Datenträgern mit hohen
> Such-Latenzen in Zusammenhang mit wahlfreiem Schreibzugriffen auf (größere)
> Dateien die Performance.
Die Aussage las sich eigentlich recht universell.
In 2016 gab es auf der FOSDEM hierzu einen Vortrag:
https://de.slideshare.net/fuzzycz/postgresql-on-ext4-xfs-btrfs-and-zfs-54525451
Die Tests wurden dabei auf einer Intel S3700 SSD durchgeführt, also
einer SSD für den schreibintensiven Servereinsatz.
Folien 33 und 34 sind recht aussagekräftig. TL;DR: btrfs ohne nodatacow
ist auch auf SSD nur halb so performant wie der Rest, inklusive ext3.
Die Kurven in Folie 37 zum Verhalten von btrfs ohne nodatacow spricht
auch Bände: extrem variabel in den TPS.
Conclusion in Folie 39 zu btrfs: "bad: rather unstable and inconsistent
behavior".
Natürlich hat sich seit 2016 viel in btrfs getan, aber ganz ehrlich: Das
würde mich eher von einem Dateisystem abwenden lassen: Wenn es sich in
einem Jahr so extrem stark verändert.
Ein ältere Blog-Eintrag von 2015 zum Thema Postgres in BTRFS gibt es
hier:
https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp
S°
--
Sigmentation fault. Core dumped.
Reply to: