Probleme effective_cache_size

palex · 26/10/2011 19:31:23

Bonsoir a tous!

J aurais voulu avoir quelques explications sur le parametre effective_cache_size et sont fonctionnement. Car en local lorsque ce parametre est desactive j ai des temps de reponse tres correct. J ai essayer comme preconise dans le fichier de conf postgres de le positionner a 1/2 de ma Ram et au 3/4 pour le mettre au taquet comme recommande sur la doc postgresql. Mais des que je l active, une requete qui prend 300ms en temps normal dure plus de 10 minutes! Voir plus...

Pourtant ce parametre se trouve dans la section querry tunning du fichier, je pensais avoir de meilleur perf avec...serais t il couple avec d autre parametre du fichier de conf a ne pas negliger?

Merci beaucoup

rjuju · 26/10/2011 19:42:57

Le paramètre effective_cache_size donne a postgresql un moyen de déterminer si une donnée qui n est pas dans le cache postgres a des chances d'être dans le cache disque du système d'exploitation.
Ainsi, une grosse valeur aura tendance a diminuer l'utilisation des index, l'accès disque étant rendu plus rapide.

Vous devriez voir un changement de plan d'exécution dans le explain qui vous permettra de voir où se trouve le problème.

De plus, après un redémarrage du serveur il est probable que les données ne soient pas dans le cache système, le gain en performance ne sera alors visible qu'une fois les données remontées dans le cache système.

Une augmentation de plus de 10 minutes est à première vue déraisonnable. Si aucun verrou ne bloque l'accès cela peut être le signe de statistiques non à jour conduisant à de très mauvais plan d'exécution. Bref, il faut chercher dans plusieurs directions.

Pour les autres paramètres de configuration, le plus important est sans doute le shared_buffers qui dimensionne le cache postgresql et contribue le plus au gain de performance. Si vous êtes sous windows, il est par contre déconseillé de le passer à plus de 512MB.

Dernière modification par rjuju (26/10/2011 19:50:16)

gleu · 26/10/2011 19:59:17

ce parametre est desactive

Aucun paramètre n'est désactivé. Il a sa valeur par défaut quand il est en commentaire.

Ainsi, une grosse valeur aura tendance a diminuer l'utilisation des index, l'accès disque étant rendu plus rapide.

Non, c'est le contraire. Avec une grosse valeur, l'index a plus de chance d'être en mémoire avec la table... donc plus de chances d'utiliser un index.

palex · 26/10/2011 20:03:35

Je suis sur linux mais ce que je comprends pas c est que la requete qui est longue s execute sur un serveur qui tourne depuis plusieurs heures, du coup le cache est deja rempli...il devrai alle vite...la je coupe le serveur en desactivant ce parametre donc sans le cache et ma requete s execute en moins de 500ms...ya un truc que je saisie pas mais je regarderais le plan d execution et les vaccums pour voir. Merci pour ces informations

palex · 26/10/2011 20:04:53

Oui ok pour la valeur par defaut je me suis mal exprime mais je me douttai qu il y avai une valeur par defaut pardon.

rjuju · 26/10/2011 20:19:51

gleu a écrit :

Ainsi, une grosse valeur aura tendance a diminuer l'utilisation des index, l'accès disque étant rendu plus rapide.
Non, c'est le contraire. Avec une grosse valeur, l'index a plus de chance d'être en mémoire avec la table... donc plus de chances d'utiliser un index.

Effectivement, encore un truc que j'avais compris de travers ^^

gleu · 26/10/2011 21:31:45

rjuju : pas de soucis

palex : il nous faudrait les plans d'exécution pour pouvoir en dire plus (EXPLAIN ANALYZE la_requete).

palex · 27/10/2011 15:09:13

bonjour!
je viens de jouer l explain analyze sur ma machine et sur une machine de qualif

voici les liens du resultat :

ma machine : http://explain.depesz.com/s/R7m
qualif : http://explain.depesz.com/s/EPD

merci de m'expliquer ce qui n'irai pas entre les 2 sachant que les bases contienne les memes index etc.. les seules chose qui changent sont les conf postgres au niveau du effective_cache_size, shared_buffer...

que préconiseriez vous comme configuration postgres sur cette machine :

ipcs -l -m

------ Limites de la mémoire partagé --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
taille minimum de segments (octets) = 1

free
total used free shared buffers cached
Mem: 2059580 2049004 10576 0 4572 1745484
-/+ buffers/cache: 298948 1760632
Swap: 2097144 14308 2082836

merci pour votre aide.

palex · 27/10/2011 15:35:25

j'ai oublié de preciser je suis en 8.4.9-0ubuntu0.10.10 (32bits) et sur la qualif en 8.4.7 on x86_64-unknown (64bits)

Dernière modification par palex (27/10/2011 16:43:11)

cedric · 27/10/2011 16:56:11

Il y a eu plusieurs améliorations en 8.4.8 et 8.4.9 sur la gestion des joins/anti-join, bitmap, etc...

1/ Pour comparez vous devez utiliser la meme version en dev et en prod. (une mise à jour de la prod est souhaitable dans tous les cas)
2/ Il est possible que la qualité des échantillons statistiques diverge entre le dev et la prod, et que le plan soit lamentable en prod en raison de ce point.

2/ est facile à vérifier (procédez a un analyze des tables mise en oeuvre), et 1/ me semble la vraie cause de votre différence de performance entre les deux (car il implique la construction d'une mauvaise optimisation)

palex · 27/10/2011 17:51:48

ok je vais voir dans quel mesure il est possible de passer en 8.4.9 voir meme 9 et supérieur! et je vais égalemetn télécharger une version 8.4.7 en local pour faire quelques test afin d'etre dans quasiment les memes conditions

merci pour votre aide

palex · 28/10/2011 12:20:09

bonjour

je viens de lancer un serveur 8.4.7 en local pour etre iso prod et j'ai executé la requete et elle utilise bien un bitmap index scan meme avec cette version donc la prod devrait faire la meme, j'ai fait des vaccum annalyze sur les bases pour que les index soient à jour mais rien ne change. donc je comprend pas.

palex · 28/10/2011 14:07:09

existe t il un moyen de mettre en debug certaines chose afin de voir pourquoi il choisi tel ou tel algorithme ? quitte a ce que j'ajoute des write dans le code source juste pour moi?

merci

gleu · 29/10/2011 08:18:00

Donc si je comprends bien, avec un 8.4.7 sur les deux serveurs, et après avoir fait un VACUUM ANALYZE (seul le ANALYZE est intéressant), vous avez les deux plans indiqués plus haut et une grosse différence en terme de temps d'exécution ?

Vous êtes sûr que les deux bases sont identiques ? pas d'index supplémentaire par exemple ? vous pouvez utiliser check_postgres.pl avec l'action same_schema pour vous en assurer.

La configuration est la même ? notamment le paramètre stats_default_target ?

Que se passe-t-il si vous désactivez le paramètre enable_indexscan sur le serveur lent ?

gleu · 29/10/2011 08:20:42

Et pour répondre spécifiquement à vos questions, mettre en debug va vous donner bien trop d'infos pour que vos logs soient réellement déchiffrables. Modifier le code source pour ça ne me paraît bien pas la bonne approche. Commencez déjà par tester ce qu'il se passe avec le enable_indexscan désactivé. Ensuite (ou avant, peu importe), comparez les statistiques correspondant aux tables impliquées dans cette requête. Oh, et souvent, le plus simple pour améliorer les performances consiste à revoir la requête.

palex · 30/10/2011 14:33:10

Ok je verrais tout cela lundi. La requete a ete revu aussi et a permis de gagner un peu de temps mais j ai un gros souci c est que j aimerais bien comprendre pourquoi la meme requete prend un temps completemet different alors que mon pc est cense etre moins rapide que la prod en plus, je verifierai les schemas au cas ou mais il s agissait d un dump puis restore.

Je vous tiens au courant des que j ai pu tester tout cela.
Merci

cedric · 02/11/2011 12:55:49

palex a écrit :

Ok je verrais tout cela lundi. La requete a ete revu aussi et a permis de gagner un peu de temps mais j ai un gros souci c est que j aimerais bien comprendre pourquoi la meme requete prend un temps completemet different alors que mon pc est cense etre moins rapide que la prod en plus, je verifierai les schemas au cas ou mais il s agissait d un dump puis restore.
Je vous tiens au courant des que j ai pu tester tout cela.
Merci

un dump& restore ne reproduit pas les éventuels espaces morts que vous avez en prod. Cela change donc les estimations d'occupations de lignes vivantes par page.
Avez-vous des volumes similaires? (comparaison rapide à la mano : dans psql, \dt+ et \di+ pour connaitre les tables avec leur volumes disque)

#1 26/10/2011 19:31:23

Probleme effective_cache_size

#2 26/10/2011 19:42:57

Re : Probleme effective_cache_size

#3 26/10/2011 19:59:17

Re : Probleme effective_cache_size

#4 26/10/2011 20:03:35

Re : Probleme effective_cache_size

#5 26/10/2011 20:04:53

Re : Probleme effective_cache_size

#6 26/10/2011 20:19:51

Re : Probleme effective_cache_size

#7 26/10/2011 21:31:45

Re : Probleme effective_cache_size

#8 27/10/2011 15:09:13

Re : Probleme effective_cache_size

#9 27/10/2011 15:35:25

Re : Probleme effective_cache_size

#10 27/10/2011 16:56:11

Re : Probleme effective_cache_size

#11 27/10/2011 17:51:48

Re : Probleme effective_cache_size

#12 28/10/2011 12:20:09

Re : Probleme effective_cache_size

#13 28/10/2011 14:07:09

Re : Probleme effective_cache_size

#14 29/10/2011 08:18:00

Re : Probleme effective_cache_size

#15 29/10/2011 08:20:42

Re : Probleme effective_cache_size

#16 30/10/2011 14:33:10

Re : Probleme effective_cache_size

#17 02/11/2011 12:55:49

Re : Probleme effective_cache_size

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux