Tout d'abord tu dois récolte

sparky/ = 15 Mai, 2006 - 15:03

Tout d'abord tu dois récolter des stats, pour savoir ce qui coince (http://docs.postgresqlfr.org/8.1/monitoring-stats.html)

Ensuite quand cela est fait (après redémarrage), tu dois juste type la requête

select * from pg_stat_activity;

pour savoir quel est la requête qui prend tant de temps et là on pourra commencer à travailler sur cette requête.

PS: sous windows il vaut mieux mettre fsync à false, cest plus rapide. Mais c'est un peu risqué : en cas de crash, tes données pourraient être corrompues. As-tu ajusté tes paramètres pour la mémoire (work_mem, shared_buffer) ?

On dirait qu'il s'agit d'un

Jean-Paul Argudo/ = 15 Mai, 2006 - 15:09

On dirait qu'il s'agit d'un checkpoint...

Soit, votre problème vient très probablement d'une saturation des I/O sur votre système.

Allez faire un tour sur cette partie de le documentation.

Pour valider le fait que vous avez des soucis avec les checkpoints, augmentez le paramètre checkpoint_segments (mettons 20 pour commencer?), et le paramètre checkpoint_timeout (à 1800 par exemple).

Si vous constatez qu'il s'agit effectivement d'un problème de checkpoint, nous pourrons alors vous conseiller plus en avant. Cependant ce ne sera pas tâche aisée sous Windows. Les plates-formes Unix offrent en effet bien plus de souplesses pour venir à bout de ce genre de problèmes.

Cordialement,

--
Jean-Paul ARGUDO
www.dalibo.com

La modification du paramètre

florent95160/ = 15 Mai, 2006 - 20:08

La modification du paramètre fsync n'a rien changé.
par contre, chekpoint_timeout et checkpoint_segment m'ont permis de diminuer l'intensité de ces pics. Merci pour l'indication. Le problème est qu'ils sont maintenant beaucoup plus nombreux.
Est-ce qu'il existe une manière de bien choisir les valeurs??
De même, comment choisir la valeur de work_mem & shared_buffer??
Je ne comprends pas le pourquoi de l'existence de ces pics. J'applique pourtant tout le temps la même procédure stockée par intervalle de 5 secondes et la variation est énorme.
Pour exemple, une procédure prenant 7secondes en moyenne, lors d'un pic, s'éxécute en plus de 50 secondes.
Je craque, aidez moi s'il vous plait...

C'est facile : les données n

sparky/ = 16 Mai, 2006 - 10:48

C'est facile : les données ne sont pas directement écrites sur disque mais passe par un "buffer" mémoire puis fichier (WAL), quand un checkpoint se produit, ce fichier est écrite (WAL) et tu dois attendre la fin du checkpoint.

voir ici pour plus d'info http://docs.postgresqlfr.org/8.1/wal-configuration.html

Je ne peux donc pas éviter c

florent95160/ = 16 Mai, 2006 - 11:13

Je ne peux donc pas éviter ces pics?? qui, si je comprends bien, sont la conséquence du REDO.
Ce qui m'étonne c'est qu'il soit cyclique (toutes les 3 ou 5 minutes)

ah lala, tu n'as pas lu la do

sparky/ = 16 Mai, 2006 - 11:48

ah lala, tu n'as pas lu la doc. Evidemement que c'est cyclique

Le processus d'écriture en tâche de fond lancera automatiquement un point de contrôle de temps en temps. Un point de contrôle est créé tous les checkpoint_segments segments de journaux ou dès que checkpoint_timeout secondes se sont écoulées. Les paramètres par défaut sont respectivement 3 segments et 300 secondes.

Si tu veux améliorer tu peux aussi mettre xlog sur un autre disque

je comprends donc pour les 3

florent95160/ = 16 Mai, 2006 - 13:47

je comprends donc pour les 3 minutes, ma valeur actuelle pour checkpoint_timeout est de 1800 secondes.... Ca colle bien :p
Je vais jouer sur ces paramètres voir si je peux diminuer l'intensité de ces pics
Merci pour l'aide