Vous n'êtes pas identifié(e).
Pages : 1
Finalement, fausse joie !
Les derniers tests n'étaient pas probants, notamment concernant la perte exponentielle que nous ne constations plus.
En effet, nous n'avions plus, dans notre jeu de test, de ligne concernée par le select for update (sic)
Le problème reste donc entier.
De mon côté, en utilisant le même code que vous (et les mêmes tables)
8.4 :
--27 550
--36 318
--32 589
--33 010
--38 720
--56 379
--43 696
--28 704
--29 031
--34 710
9.3 :
--53 758
--44 179
--39 110
--37 503
--51 059
--68 345
--62 526
--41 372
--43 275
Je ne suis pas sur que l'on puisse en tirer quoi que ce soit. Éventuellement que cela est quand-même plus long en 9.3.
Ceci étant dit, nous avons trouvé l'explication à la dégradation exponentielle que nous constations en 9.3. Il s'agissait d'une différence entre les deux postgres.conf
Bref, pour conclure sur la batterie de tests du jour :
- la 9.3 reste plus lente sur la gestion de slock explicite
- la dégradation exponentielle se corrige via "bon" paramétrage du postgres.conf
Bonjour, et merci pour cette réponse,
La déperdition se manifeste avec une nombre d'itérations > 1000, voire > 10 000. La déperdition semble alors exponentielle.
Voici le code utilisé, et exécuté directement via pgadmin, sur une base identique 8.4 et 9.3.
La procédure est lancée via un "select * from jpi_test_perf_chronos()" tout simple
A noter que les tables etablissement et param_chrono contiennent moins de 50 enreg :
---------------------------------------------------------
CREATE OR REPLACE FUNCTION jpi_test_perf_chronos()
RETURNS VOID AS
$BODY$
DECLARE
x INTEGER := 0;
y INTEGER;
BEGIN
LOOP
select 1 from param_chrono into y where chron_table = 'facture' for UPDATE;
select 1 into y from etablissement limit 1;
update param_chrono set chron_chrono = chron_chrono where chron_table = 'facture';
x := x +1 ;
IF x >= 9999 THEN
EXIT;
END iF ;
END LOOP;
RETURN;
END
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
------------------------------------------------------------------------------
En 8.4 => 4300 ms
En 9.3 => 19 500 ms (...)
Bonjour
Nous constatons une déperdition importante de performance entre la 8.4 et la 9.3 sur le lock explicite
Nous travaillons sur une table nommée "chrono" pour l'exemple, qui contient moins de 50 lignes
Le code concerné est le suivant :
-----------------------------------------------------
begin
for 1 to 1000
select * from chrono where [where_condition] FOR UPDATE
do stuff (or not…..)
update chrono set [set_clause] where [where_condition]
end for
commit
--------------------------------------------------------
En 8.4, no problem: le temps de chaque boucle reste homogène, du début à la fin.
En 9.3, il y a une déperdition exponentielle !
Nos tests montrent qu'une façon "simple" de résoudre le problème serait de faire un commit après chaque update de chrono, afin de "libréer" le lock.
Mais, mais, mais: faire cela a d'énormes conséquences par ailleurs, sur notre application (pour faire simple, une réécriture très lourde, chronophage et impactante)
Une idée ou une explication ?
Merci
Pages : 1
