Trop d'E / S générées par le processus du collecteur de statistiques postgres

10

J'utilise XenServer avec plusieurs machines virtuelles ayant des bases de données postgres locales. Même lorsque toutes les applications sont inutilisées et que les bases de données sont inactives, chaque vm provoque un trafic réseau de stockage constant qui dégrade les performances du périphérique de stockage iscsi.

Après avoir exécuté, iotopj'ai remarqué que le processus du processus de collecte des statistiques postgres écrit constamment sur le disque à un taux d'environ 2 Mo / s.

J'ai ensuite désactivé la collecte de statistiques en modifiant /etc/postgresql/8.4/main/postgresql.conf:

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

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

comme suggéré dans http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm .

Cela a éliminé l'écriture continue, mais y a-t-il des inconvénients à désactiver le suivi des statistiques?

Ou devrais-je plutôt placer le répertoire pg_stat_tmp sur un disque virtuel pour éviter le trafic disque / réseau?

Le système est une Debian 6.0.7 (squeeze) à jour avec postgres 8.4 et environ 20 bases de données avec environ 50 tables, la taille totale du fichier de vidage est inférieure à 100 Moctets.

— nn4l
source

7

Étant donné que la mise à niveau de PostgreSQL n'est pas une option, j'ai essayé de placer le répertoire pg_stat_tmp sur un système de fichiers tmpfs, ce qui a permis une amélioration significative des performances. J'exécute maintenant cela sur quelques dizaines de systèmes depuis quelques mois sans aucun inconvénient notable.

Pour ce faire, montez simplement pg_stat_tmp avec tmpfs dans votre fichier / 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

— nn4l
source

Je l'ai fait pour Postgresql 9.1. Un de mes serveurs avait une écriture continue de 1 Mo / s tout au long de la journée. Cela l'a fait tomber à presque rien. Il est approuvé par les docs , BTW: "... Le fait de pointer cela vers un système de fichiers basé sur la RAM réduira les exigences d'E / S physiques et peut améliorer les performances."

— Halfgaar

0

Mettez à niveau PostgreSQL. Au minimum absolu, assurez-vous que vous êtes sur la dernière version 8.4; si cela ne résout pas le problème et qu'il est pratique de le faire, vous devriez probablement passer à la version 9.2. Au moins certains problèmes concernant le collecteur de statistiques ont été résolus depuis la version 8.4 et arriveront en fin de vie dans environ un an . Vous pourrez peut-être trouver plus d'informations en cherchant dans les archives de la liste de diffusion pgsql-general .

Vous ne devriez pas avoir trop de problèmes lors de la mise à niveau de la version 8.4 vers la version 9.2, mais comme d'habitude, vous devez lire la section de mise à niveau des notes de version pour chaque version .0 intermédiaire (9.0, 9.1 et 9.2). Portez une attention particulière à standard_conforming_stringset bytea_output.

— Craig Ringer
source

0

Même problème ici. J'ai aussi désactivé track_*et ainsi de suite.

L'effet secondaire est que l' autovacuumutilisation de ces données collectées se déclenche.

Donc, je prends soin de programmer une soirée vacuumdb.

Une autre solution consiste à régler autovacuum_naptimesuffisamment haut pour que le système soit au repos.

— Gelma
source