Postgres DISK IO très élevé. Que puis-je faire pour le réduire immédiatement?

Je suis conscient que des disques plus rapides que ceux que j'utilise aideront mais cela prendra plus de temps à installer et j'essaie d'utiliser des mesures d'urgence pour réduire les E / S de disque. atop signale l'utilisation du DSK sur le rouge presque constamment. C'est pour postgres 8.3.

Mon paramètre shared_buffers est à 24 Mo, bien que le serveur dispose de 16 Go de RAM qui ne sont pas pleinement utilisés. Ma première pensée a été de donner à la base de données autant de RAM que possible, mais je ne sais pas comment faire (c'est un serveur de base de données dédié).

Toute solution qui ne nécessite pas de redémarrage est préférable, mais je prendrai ce que je peux obtenir à ce stade.

Merci!

Le paramètre shared_buffers de 24 Mo est la valeur par défaut conservatrice, je dirais qu'il doit être beaucoup plus élevé pour une base de données dédiée avec 16 Go de RAM disponibles. Mais oui, vous devrez redémarrer le serveur pour le redimensionner. http://wiki.postgresql.org/wiki/Performance_Optimization est un bon point de départ pour les directives de configuration des performances. Définir les shared_buffers sur 4 Go ou 6 Go semble plus raisonnable.

Notez que sous Linux, vous devez ajuster le paramètre kernel.shmmax sysctl (dans /etc/sysctl.conf ou simplement en écrivant / proc / sys / kernel / shmmax) pour allouer un bloc de cette mémoire partagée. Si vous ne le faites pas, vous obtiendrez une erreur spécifiant le montant demandé, vous devez définir kernel.shmmax plus haut que cela.

Puisque vous avez beaucoup de mémoire, vous pouvez également envisager de définir le work_mem par défaut plus haut, ce qui fera que les tris et les hachages (groupe / ordre / distinct, etc.) auront tendance à fonctionner en mémoire plutôt qu'à utiliser des fichiers temporaires. Vous n'avez pas besoin de redémarrer le serveur pour ce faire, il suffit de mettre à jour le fichier de configuration, de recharger le service et les nouvelles sessions obtiendront le nouveau paramètre. La mémoire de travail par défaut pour une session est de 1 Mo. Vous pouvez calculer le maximum pouvant être utilisé à la fois work_mem * max_client_connectionset estimer l'impact que cela aura.

Vous devez également augmenter la taille effective_cache_size pour indiquer au planificateur que la couche FS du noyau est susceptible de mettre en cache un grand nombre de pages en mémoire en dehors des tampons partagés de postgresql.

etc. etc. espérons que cela vous permettra de prendre un bon départ.

Remontez les disques avec noatime

Mis à part les suggestions données ici, vous voudrez peut-être également examiner vos paramètres de vide automatique. Par défaut, il se déclenchera après environ 50 mises à jour et si votre base de données fait beaucoup de mises à jour / insertions, cela peut déclencher une quantité inutile d'instructions de vide qui généreront beaucoup d'E / S.

Sur un système qui est très proche du débit d'E / S maximal pendant le fonctionnement normal, vous souhaiterez peut-être augmenter checkpoint_completion_target pour réduire la charge d'E / S des points de contrôle . L'inconvénient est que la prolongation des points de contrôle affecte le temps de récupération, car davantage de segments WAL devront être conservés pour une utilisation possible dans la récupération

Voir plus ici .

Si le diskio du postgresql est très élevé, vous devez vérifier les instructions en cours d'exécution, en particulier pour les instructions, faire un "tri sur disque" et définir des index appropriés.

Juste google pour "Postgresql Performance Tuning", vous trouverez assez de biches par où commencer.