Troppa I / O generata dal processo di raccolta delle statistiche di Postgres


10

Sto usando XenServer con diverse macchine virtuali con database Postgres locali. Anche quando tutte le applicazioni sono inutilizzate e i database sono inattivi, ogni VM causa un traffico di rete di archiviazione costante che degrada le prestazioni del dispositivo di archiviazione iscsi.

Dopo l'esecuzione, iotopho notato che il processo di processo di raccolta delle statistiche postgres scrive costantemente sul disco a una velocità di circa 2 MByte / s.

Ho quindi disabilitato la raccolta di statistiche modificando /etc/postgresql/8.4/main/postgresql.conf:

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

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

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

Ciò ha eliminato la scrittura continua, ma ci sono degli svantaggi nel disattivare il monitoraggio delle statistiche?

O dovrei piuttosto posizionare la directory pg_stat_tmp su un ramdisk per evitare il traffico su disco / rete?

Il sistema è un Debian 6.0.7 (spremere) aggiornato con postgres 8.4 e circa 20 database con circa 50 tabelle, la dimensione totale del file di dump è inferiore a 100 MByte.

Risposte:


7

Poiché l'aggiornamento di PostgreSQL non è un'opzione, ho provato a posizionare la directory pg_stat_tmp su un file system tmpfs, che ha prodotto un miglioramento significativo delle prestazioni. Ora sto eseguendo questo su alcune dozzine di sistemi per un paio di mesi senza alcun inconveniente evidente.

Per fare questo, monta semplicemente pg_stat_tmp con tmpfs nel tuo file / etc / fstab:

# <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

L'ho fatto per Postgresql 9.1. Uno dei miei server ha avuto una scrittura continua di 1 MB / s durante il giorno. Ciò ha fatto cadere quasi a nulla. È approvato dai documenti , BTW: "... Puntare questo su un file system basato su RAM ridurrà i requisiti di I / O fisici e può portare a prestazioni migliori."
Halfgaar

0

Aggiorna PostgreSQL. Come minimo assoluto, assicurati di essere sull'ultima versione 8.4; se questo non lo risolve ed è pratico farlo, probabilmente dovresti passare a 9.2. Almeno alcuni problemi relativi al raccoglitore di statistiche sono stati risolti dall'8.4 e raggiungeranno la fine del ciclo di vita tra circa un anno . Potresti essere in grado di trovare maggiori informazioni cercando negli archivi della mailing list pgsql-general .

Non dovresti avere troppi problemi nell'aggiornamento da 8.4 a 9.2, anche se come al solito devi leggere la sezione di aggiornamento delle note di rilascio per ciascuna versione .0 tra (9.0, 9.1 e 9.2). Prestare particolare attenzione a standard_conforming_stringse bytea_output.


0

Lo stesso problema qui. Ho anche disabilitato track_*e così via.

L'effetto collaterale è che autovacuumsta usando questi dati raccolti per accendersi.

Quindi, mi occupo di programmare ogni notte a vacuumdb.

Un'altra soluzione è quella di impostare un autovacuum_naptimelivello abbastanza alto da avere il sistema a riposo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.