From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr> |
Cc: | pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>, Pierre <pierre(dot)dupre(at)meteo(dot)fr> |
Subject: | Re: Problème de select suivant un update |
Date: | 2008-06-05 12:03:30 |
Message-ID: | 4847D612.10805@lelarge.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Guillaume Lelarge a écrit :
> Valérie SCHNEIDER a écrit :
>> [...]
>> Question: je suis très surpris du temps de sélection
>> du cas (3) qui est très grand par rapport aux autres
>> select, et pour ne récupérer aucune ligne (car un
>> update précédent les a déplacées).
>>
>
> Pour être franc, moi aussi. Je viens de faire sept tests (et j'en
> prépare un huitième qui s'exécutera pendant que je dormirais), tous ont
> à peu de choses près la même durée d'exécution alors que le paramétrage
> est bien différent. Je n'ai pas encore tout analysé car j'évite
> d'utiliser ma machine pendant le test, mais il semble que j'avais raison
> pour les écritures pendant le premier SELECT et l'absence d'écritures
> pendant le second. Cependant, ma conclusion me paraît maintenant
> suspecte. Je vais continuer à me pencher dessus car j'avoue que je ne
> comprends pas du tout ce qu'il se passe (et ça m'ennuie beaucoup :) ).
>
Je viens de faire un petit tableau sur les neuf tests que j'ai
finalement fait (les nombres sont des secondes) :
UPDATE ANALYZE CHECKPOINT SELECT SELECT
Test 1 992 292 0,02
Test 2 945 27,31 13,7 275,52 0,02
Test 3 942 33 22 724 2,14
Test 4 946 31 29 709 2,5
Test 5 924 47 21 644 0,3
Test 6 942 33 9,8 699 1,3
Test 7 953 33,8 9,99 683 1
Test 8 810 26 99 23 8
Test 9 869 32 9,7 375 45
Il est tout à fait étonnant que je multiplie par 3 le temps pour le
premier SELECT entre les tests 2 et 3 (la seule différence entre les
deux est la config où j'ai passé les checkpoint_segments de 3 à 30).
On remarque que le temps d'exécution de l'UPDATE ne varie presque pas,
sauf sur les tests 8 et 9 (particularité de ces tests, un
effective_cache_size passé de 128 Mo, valeur par défaut, à 1 Go)
Le test intéressant est le 8.
Différence de config entre test 7 et test 8 :
* passage de shared_buffers de 50 Mo à 1 Go
* passage de effective_cache_size de 128 Mo à 1 Go
Différence de config entre test 8 et test 9 :
* passage de shared_buffers de 1 Go à 50 Mo
* passage de effective_cache_size de 1 Go à 1,3 Go
Différence entre votre config et la mienne :
* passage de shared_buffers de 32 Mo à 1 Go
* passage de wal_buffers de 64 Ko à 1 Mo
* passage de checkpoint_segments de 3 à 30
* passage de checkpoint_timeout de 5min à 15 min
* passage de effective_cache de 128 Mo à 1 Go
(j'ai supprimé les différences inintéressantes du côté des perfs)
Je voulais rejouer le test 8 mais je viens de m'apercevoir, en
redémarrant, j'ai perdu la base :-/
Je dois la reconstruire, ça va prendre un peu de temps. À faire :
* de nouveau le test 8
* un test en modifiant la quantité de stats sur la table.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2008-06-05 12:13:29 | Re: Problème de select suivant un update |
Previous Message | Guillaume Lelarge | 2008-06-04 23:57:34 | Re: Problème de select suivant un update |