Spiky COMMIT entraîne des ralentissements des performances avec Postgres 8.4

Question

Nous venons d'installer la surveillance des performances sur notre application Web et nous constatons une tendance irrégulière dans les temps de réponse de notre serveur Postgres 8.4.Les pics correspondent à un ralentissement important de notre application Web.Le temps semble largement pris dans "Postgres commit" :

Nous auto-hébergons Postgres 8.4.3 sur Ubuntu 10.04, avec essentiellement des paramètres de stock, sur une instance Amazon EC2 c1.xlarge avec EBS.Oui, je sais que Postgres sur EBS n'est probablement pas la meilleure configuration.Nous prévoyons de passer à une base de données Postgres plus récente sur RDS plus tard cette année.

En attendant, y a-t-il quelque chose d’évident que je devrais examiner et qui pourrait apprivoiser ce motif hérissé ?

Answer 1

Il est difficile de dire exactement ce que disent vos graphiques.Mais commit est conçu pour être lent.Par défaut, Postgres attend que les modifications soient écrites sur le disque avant qu'il ne laisse commit retour.

Vous pouvez laisser commit terminer avant que les modifications ne soient écrites sur le disque avec cette option :

synchronous_commit = off

Cela devrait certainement aider à répartir les E/S disque requises pour commit sur plus de temps.L'inconvénient est qu'une panne de serveur peut entraîner la perte des transactions terminées.