Postgres: Prüfpunkte Auftretende zu häufig

Question

Wir haben einen starken Postgres-Server (64 Cores, 384 GB RAM, 16 15k SAS-Laufwerke, RAID 10), und mehrmals im Laufe des Tages haben wir mehr großen Datensätze neu zu erstellen, die sehr schreibintensive . Apache und Tomcat laufen auch auf demselben Server.

Wir bekommen diese Warnung über 300-mal pro Tag, während diese Datensätze wieder aufzubauen, mit langen Strecken, wo die Fehler sind durchschnittlich 2 bis 5 Sekunden auseinander:

2015-01-15 12:32:53 EST [11403]: [10841-1] LOG: checkpoints are occurring too frequently (2 seconds apart) 
2015-01-15 12:32:56 EST [11403]: [10845-1] LOG: checkpoints are occurring too frequently (3 seconds apart) 
2015-01-15 12:32:58 EST [11403]: [10849-1] LOG: checkpoints are occurring too frequently (2 seconds apart) 
2015-01-15 12:33:01 EST [11403]: [10853-1] LOG: checkpoints are occurring too frequently (3 seconds apart) 

Dies sind die zugehörigen Einstellungen:

checkpoint_completion_target 0.7 
checkpoint_segments 64 
checkpoint_timeout 5min 
checkpoint_warning 30s 
wal_block_size 8192 
wal_buffers  4MB 
wal_keep_segments 5000 
wal_level hot_standby 
wal_receiver_status_interval 10s 
wal_segment_size 16MB 
wal_sync_method  fdatasync 
wal_writer_delay 200ms 
work_mem 96MB 
shared_buffers 24GB 
effective_cache_size 128GB 

Das bedeutet, dass wir alle 2 - 5 Sekunden 1024 MB WAL-Dateien schreiben, manchmal 15 - 30 Minuten lang.

1) Sehen Sie irgendwelche Einstellungen, die wir verbessern können? Lassen Sie es mich wissen, wenn Sie weitere Einstellungen benötigen.

2) Können wir verwenden "SET LOCAL synchronous_commit TO OFF;" zu Beginn dieser schreibintensiven Transaktionen, damit diese WAL-Schreibvorgänge etwas mehr im Hintergrund ablaufen und weniger Auswirkungen auf die restlichen Operationen haben?

Die Daten, die wir neu aufbauen, werden an anderer Stelle gespeichert, so dass die Stromversorgung fehlgeschlagen UND die RAID-Batterie-Sicherung hat ihren Job nicht erledigt, wir haben nichts verloren, sobald die Datenmenge wieder aufgebaut wird.

Würde "LOCAL synchronous_commit auf OFF gesetzt;" Probleme verursachen, wenn dies 15 - 30 Minuten dauert? Oder verursachen Sie Probleme mit unserer Streaming-Replikation, die WAL-Absender verwendet?

Danke!

PS. Ich hoffe, dass Samsung beginnt, seine SM1715 3.2 TB PCIe Enterprise SSD zu verschicken, da ich denke, dass es unsere Probleme gut lösen würde.

Answer 1

Der Server erzeugt so viel WAL Daten aufgrund der wal_level auf hot_standby. Ich gehe davon aus, dass Sie dies benötigen, also ist die beste Option, um die Warnungen zu vermeiden, Ihre checkpoint_segments zu erhöhen. Aber sie sind nur das - Warnungen - es ist ziemlich üblich und völlig normal, sie während Bulk-Updates und Datenladungen zu sehen. Sie aktualisieren gerade häufig.

Ändern synchronous_commit ändert sich nicht, was mit dem wal geschrieben ist, sondern der Zeitpunkt, wenn der Commit kehrt das Betriebssystem zu erlauben, diese Schreiben zu puffern.

Es kann nicht zu Ihrem Schema anwenden, aber Sie könnten möglicherweise durch die Verwendung nicht protokollierte Tabellen für Ihre Daten neu erstellt einige WAL-Daten speichern. Ihre Replikate hätten keinen Zugriff auf diese Tabellen, aber nach der Neuerstellung könnten Sie Ihre protokollierten Tabellen von ihren nicht protokollierten Geschwistern aktualisieren.