Zu viele E / A werden durch den Postgres-Statistiksammlerprozess generiert


10

Ich verwende XenServer mit mehreren virtuellen Maschinen mit lokalen Postgres-Datenbanken. Selbst wenn alle Anwendungen nicht verwendet werden und die Datenbanken inaktiv sind, verursacht jede VM einen konstanten Speichernetzwerkverkehr, der die Leistung des iscsi-Speichergeräts beeinträchtigt.

Nach dem Ausführen habe iotopich festgestellt, dass der Prozess des Postgres-Statistiksammlerprozesses ständig mit einer Geschwindigkeit von ca. 2 MByte / s auf die Festplatte schreibt.

Ich habe dann das Sammeln von Statistiken durch Bearbeiten deaktiviert /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

wie in http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm vorgeschlagen .

Dadurch wurde das kontinuierliche Schreiben beseitigt. Gibt es jedoch Nachteile beim Deaktivieren der Statistikverfolgung?

Oder sollte ich das Verzeichnis pg_stat_tmp lieber auf einer Ramdisk ablegen, um den Festplatten- / Netzwerkverkehr zu vermeiden?

Das System ist ein aktuelles Debian 6.0.7 (Squeeze) mit Postgres 8.4 und ungefähr 20 Datenbanken mit ungefähr 50 Tabellen. Die Gesamtgröße der Dump-Datei beträgt weniger als 100 MByte.

Antworten:


7

Da ein Upgrade von PostgreSQL keine Option ist, habe ich versucht, das Verzeichnis pg_stat_tmp in einem tmpfs-Dateisystem abzulegen, was zu einer deutlichen Leistungsverbesserung führte. Ich lasse dies jetzt für ein paar Monate auf ein paar Dutzend Systemen laufen, ohne merkliche Nachteile.

Hängen Sie dazu einfach pg_stat_tmp mit tmpfs in Ihre Datei / etc / fstab ein:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

Ich habe das für Postgresql 9.1 gemacht. Einer meiner Server hatte den ganzen Tag über einen kontinuierlichen Schreibvorgang von 1 MB / s. Dies ließ es auf fast nichts fallen. Es wird von den Dokumenten übrigens genehmigt : "... Wenn Sie dies auf ein RAM-basiertes Dateisystem
hinweisen

0

Aktualisieren Sie PostgreSQL. Stellen Sie mindestens sicher, dass Sie auf der neuesten Version 8.4 sind. Wenn dies nicht der Fall ist und dies praktisch ist, sollten Sie wahrscheinlich ein Upgrade auf 9.2 durchführen. Zumindest einige Probleme rund um den Statistiksammler wurden seit 8.4 behoben und werden in etwa einem Jahr das Ende ihrer Lebensdauer erreichen . Weitere Informationen finden Sie möglicherweise in den Archiven der pgsql-allgemeinen Mailingliste .

Sie sollten nicht zu viele Probleme beim Upgrade von 8.4 auf 9.2 haben. Wie üblich müssen Sie jedoch den Upgrade-Abschnitt der Versionshinweise für jede .0-Version dazwischen (9.0, 9.1 und 9.2) lesen. Achten Sie besonders auf standard_conforming_stringsund bytea_output.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.