Frage Was ist das beste Dateisystem für die Insert-Performance auf PostgreSQL?


Ich bin neugierig, ob irgendjemand da draußen irgendwelche Experimente oder Vergleiche zwischen Dateisystemen und Datenbankleistung durchgeführt hat. Unter Linux frage ich mich, was das optimale Dateisystem für eine Postgres-Datenbank ist. Welche Einstellungen (Inode, etc) sind dafür ideal? Ist das etwas, das sich aufgrund der Daten in der Datenbank drastisch unterscheiden kann?

Wenn Sie nach einer Frage bezüglich der allgemeinen Dateisystem- / Datenbankleistung suchen, dieser Beitrag hat ein paar gute Informationen.

Allerdings würde ich gerne so viele Ratschläge erhalten einfügen Leistung gegenüber Leseleistung wie möglich. Danke für all die tollen Antworten!


20
2018-05-29 08:20


Ursprung


Das beste Dateisystem wäre mehr Speicher? ;) - Oskar Duveborn
+1 für Oskar. Wir gingen gerade von einer Serverkonfiguration, in der RAM ~ 33% der Gesamtgröße der DB zu einer neuen Maschine war, in der gesamter RAM größer als die Größe der DB war. Jetzt können wir die gesamte DB im Speicher zwischenspeichern. Unsere langsamste SQL-Abfrage ist jetzt 2 Größenordnungen schneller. - KevinRae


Antworten:


Kaufen Sie eine Kopie von "postgresql high performance" von Greg Smith. Es ist großartig Buch und zwei oder mehr Kapitel befassen sich mit Festplattenhardware und Dateisystemen. Du wirst viel lernen.

Kurz gesagt: Es gibt keine kurze Antwort.

Aber ich werde versuchen zu summieren:

  • Verwenden Sie nicht ext2, bis Sie wissen, was Sie tun.
  • mit ext3 Vorsicht vor Checkpoint-Spitzen wegen fsync-Aufrufen, siehe Seite 113 und 82 und 79
  • Verwenden Sie ext4 oder xfs
  • Es gibt andere Möglichkeiten

Aber da Sie sich wirklich fragen, was FS zu verwenden, Du solltest das Buch lesen!


14
2018-04-29 22:45



Einverstanden, das ist die Art von Thema, die Greg sehr gut behandelt. Es gibt ein Beispielkapitel bei packtpub.com/sites/default/files/... wenn Sie vor dem Ausleihen oder Kauf des Buches eine Bewertung vornehmen möchten. - sciurus
Lustig, als ich dieses Problem hatte, existierte das Buch nicht. Nun, ich bin wirklich dankbar für die Mühe, die Greg in dieses Buch gesteckt hat. - Elijah
Ich habe eine andere Kopie gekauft, nur um diese großartige Arbeit zu ehren :-) - Janning


Zuallererst möchten Sie zuerst ein zuverlässiges Dateisystem und eine schnelle Sekunde. Was einige Optionen ausschließt ...

Leistungstests zeigen, dass XFS oft die beste Leistung bietet. Es gibt einige Probleme mit der Stabilität, sobald Sie zu Festplatten-sehr-fast-bis-voll-Szenarien kommen. Solange Sie jedoch darauf achten, dass dies nicht geschieht, erhalten Sie eine etwas bessere Leistung.

Theoretisch benötigen Sie kein Journaling-Dateisystem für das Verzeichnis pg_xlog, aber der Geschwindigkeitsunterschied ist normalerweise so gering, dass es sich nicht lohnt. Für das Datenverzeichnis sollten Sie immer ein Metadaten-Journaling-Dateisystem haben.


6
2018-06-05 08:39



Vielleicht möchten Sie / XFS verwenden, um eine Datenbank zu speichern, weil sie (wenn nötig) Blöcke, die nicht wiederhergestellt werden können, auf Null setzen kann. - Avery Payne


Datenbankverwaltungssysteme implementieren ihr eigenes Journaling über die Datenbankprotokolle, sodass die Installation eines solchen DBMS auf einem Journaled File System die Leistung durch zwei Mechanismen beeinträchtigt:

  1. Redundantes Journaling erhöht die Festplattenaktivität

  2. Das physikalische Laufwerkslayout kann fragmentiert sein (obwohl einige Journaling-Dateisysteme über Mechanismen verfügen, um dies zu bereinigen).

  3. Viele Festplattenaktivitäten können das Journal füllen, was zu fehlerhaften "Festplatten voll" -Bedingungen führt.

Ich habe vor einigen Jahren eine Instanz gesehen, bei der dies auf einem LFS-Dateisystem bei einer Baan-Installation auf einer HP / UX-Box gemacht wurde. Das System wies anhaltende Probleme mit der Leistung und der Datenbeschädigung auf, die nicht diagnostiziert wurden, bis jemand herausfand, dass die Dateisysteme mit LFS formatiert waren.

Volumes, die Datenbankdateien enthalten, haben normalerweise eine kleine Anzahl großer Dateien. DBMS-Server haben normalerweise eine Einstellung, die konfiguriert, wie viele Blöcke in einer einzelnen E / A gelesen werden. Kleinere Zahlen wären für Transaktionsverarbeitungssysteme mit hohem Volumen geeignet, da sie das Zwischenspeichern redundanter Daten minimieren würden. Größere Zahlen wären für Systeme wie Data-Warehouses geeignet, die eine Menge sequentieller Lesevorgänge ausführen. Wenn möglich, optimieren Sie die Dateisystemzuweisungsblockgröße so, dass sie dieselbe Größe wie der Multiblock-Lesevorgang aufweist, auf den das DBMS eingestellt ist.

Einige Datenbankverwaltungssysteme können Raw-Festplattenpartitionen ausführen. Dies ergibt einen unterschiedlichen Leistungsgewinn, typischerweise weniger bei einem modernen System mit viel Speicher. Bei älteren Systemen mit weniger Speicherplatz für die Zwischenspeicherung von Dateisystem-Metadaten waren die Einsparungen bei der Festplatten-I / O recht hoch. Raw-Partitionen erschweren die Verwaltung des Systems, bieten jedoch die beste verfügbare Leistung.

RAID-5-Volumes verursachen mehr Schreibaufwand als RAID-10-Volumes, sodass eine ausgelastete Datenbank mit viel Schreibdatenverkehr auf einem RAID-10 besser (oft wesentlich besser) arbeitet. Protokolle sollten physisch getrennte Datenträgervolumes zu den Daten hinzugefügt werden. Wenn Ihre Datenbank groß ist und meist nur gelesen wird (z. B. ein Data Warehouse), kann es sinnvoll sein, sie auf RAID-5-Volumes zu speichern, wenn dadurch der Ladevorgang nicht unnötig verlangsamt wird.

Write-Back-Caching auf einem Controller kann zu einem Performance-Gewinn führen, auf Kosten der Erstellung einiger (einigermaßen unwahrscheinlicher aber möglicher) Fehlermodi, bei denen Daten beschädigt werden könnten. Der größte Leistungsgewinn dafür ist die hohe Zugriffslast. Wenn Sie dies tun möchten, sollten Sie in Erwägung ziehen, die Protokolle auf einem separaten Controller zu speichern und das Rückschreib-Caching für die Protokollvolumes zu deaktivieren. Die Protokolle haben dann eine bessere Datenintegrität, und ein einzelner Fehler kann nicht sowohl das Protokoll- als auch das Datenvolumen ausschließen. Auf diese Weise können Sie eine Sicherung wiederherstellen und die Protokolle wiederherstellen.


4
2018-05-29 09:14



Journaling Daten verschlechtert die Leistung; Journaling-Metadaten sollten im schlimmsten Fall minimale Auswirkungen haben und höchstwahrscheinlich fast keine. Nicht-Journaling Metadaten sind nicht zu empfehlen. - niXar
Ich denke, du hast den Artikel falsch verstanden. Jedes Dateisystem hat Dateisystem-Metadaten und jeder Plattenverkehr beinhaltet Lesen oder Schreiben. Moderne Computer verfügen normalerweise über genügend Arbeitsspeicher, um diese Dateisystemmetadaten einfach zwischenzuspeichern, ältere Maschinen jedoch nicht. Dies bedeutete, dass Festplattenzugriffe einen erheblichen zusätzlichen I / O-Overhead zur Folge hatten (die oft zitierte Zahl für Oracle war ein 30% iger Leistungseinbruch gegenüber unformatierten Partitionen), um die Metadaten des Dateisystems zu lesen oder zu aktualisieren. Auf einem modernen System mit mehr RAM werden die Dateisystem-Metadaten mit höherer Wahrscheinlichkeit zwischengespeichert, so dass der Overhead geringer ist. - ConcernedOfTunbridgeWells
Dies enthält einige gute allgemeine Ratschläge, aber ich habe einen Downvoted, weil es auch Informationen enthält, die irrelevant oder falsch für PostgreSQL- und moderne Journaled-Dateisysteme sind. - sciurus


Ich habe einen so detaillierten Bericht gemacht, aber es ist so nur auf Französisch. Wenn Sie Französisch lesen oder mit automatischen Übersetzungstools zufrieden sind ... Sie können die Methode wiederverwenden und für sich selbst ausführen.

Zusammenfassung: Ich habe pgbench benutzt. Der Linux I / O-Scheduler hat nur sehr wenig Bedeutung für Performances und das Dateisystem. Also, wenn Sie in Eile sind, wählen Sie einfach den Standard. Ich habe JFS gewählt.


3
2018-06-09 09:16





Dateisystem ist nur ein Teil des Problems. Sie können einen erheblichen Leistungsschub erzielen, indem Sie Ihren IO-Scheduler ändern. Glücklicherweise ist dies relativ einfach zu testen, da Sie den E / A-Scheduler im laufenden Betrieb ändern können. Ich schlage vor, jeden für ein paar Tage unter typischer Last zu versuchen und zu sehen, welche die beste Leistung gibt.


2
2018-06-05 08:46



Meine Benchmarks zeigten sehr wenig Änderungen beim Ändern des I / O-Schedulers, wahrscheinlich weil jedes DBMS bereits einen eigenen Scheduler hat. - bortzmeyer
MySQL bewältigt viel besser unter hoher Last durch die Verwendung des Terminplaners. - David Pashley


Ich habe vor ein paar Monaten einige Tests gemacht:

Ich hatte ein kleines Testprogramm, das 50 Threads erstellte, wobei jeder Thread 1000 (oder wenn es 10000 war) Zeilen in dieselbe Tabelle einfügte.

  • Mit der Datenbank auf EXT3 und einem 4-Platten-RAID5 dauerte es 50 Sekunden.
  • Mit der Tabelle auf der Ramdisk (mit Tablespace) dauerte es noch 50 Sekunden. Der Grund, warum es nicht schneller war, ist, dass alles im Verzeichnis pg_xlog protokolliert wird, das sich immer noch auf demselben RAID 5 befindet.
  • Ich habe den pg_xlog auf einen 4-Disk RAID0 (Stripe) verschoben und das gleiche Programm läuft in 40 Sekunden.
  • Zu Testzwecken habe ich den pg_xlog auf die Ramdisk verschoben und alles andere auf dem EXT3 4 Disk RAID. Das Programm wurde nach weniger als 5 Sekunden beendet.

Aber das pg___xlog auf einer Software-Ramdisk ist keine Option: Wenn Sie den Inhalt des pg_xlog-Verzeichnisses verlieren, wird postgres nicht gestartet. (Es gibt jedoch Hardware-Ramdisks mit Batterie-Backup, die von Interesse sein könnten.)

IMHO: Verwenden Sie das Dateisystem, mit dem Sie am besten vertraut sind, für die Datenbankdateien. Verschieben Sie den pg_xlog (mit einem Symlink, siehe Dokumentation) zum schnellstmöglichen Gerät, das Sie haben.


2
2018-06-15 03:02



pgbench macht etwas ähnliches und ist in den meisten Installationen enthalten. - Avery Payne


Nach einigen Jahren im Graben beantworte ich ZFS und SmartOS.

Hier ist ein Papier zu den Benchmarks: https://www.joyent.com/public-cloud/benchmarks/postgresql


1
2018-04-10 03:50





Ich habe gesehen, dass ich mich daran erinnert habe, dass ein optimiertes FreeBSD Ihnen im Vergleich zu anderen Betriebssystemen etwas mehr Leistung bringen wird. Obwohl ich sicher bin, dass diese Information veraltet ist und wahrscheinlich in erster Linie ein Mythos ist. Aber du kannst es trotzdem ausprobieren, siehe diese Richtlinie für die Kernel-Einstellungen: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html


0
2018-06-05 09:38