Vous n'êtes pas identifié(e).
Pages : 1
Si mes calculs sont corrects, ça fait une moyenne de 6.7 Mo/s en lecture séquentielle, ce qui est très très peu.
Ci-dessous les tous nouveaux comptes rendu EXPLAIN pour vous demandez votre avis :
Et maintenant que la taille disque a été augmentée et VACUUM FULL exécuté, est-ce que les performances de la lecture séquentielle se sont améliorées ?
-----------------------------------------------
EXPLAIN (ANALYSE,BUFFERS) SELECT COUNT(*) FROM wois_alarm
-----------------------------------------------
Aggregate (cost=218661.05..218661.06 rows=1 width=0) (actual time=16977.133..16977.134 rows=1 loops=1)
Buffers: shared hit=15339 read=89108
-> Seq Scan on wois_alarm (cost=0.00..195818.24 rows=9137124 width=0) (actual time=0.039..8791.853 rows=9137124 loops=1)
Buffers: shared hit=15339 read=89108
Planning time: 0.093 ms
Execution time: 16977.185 ms
-----------------------------------------------
EXPLAIN (ANALYSE,BUFFERS) UPDATE wois_alarm SET engine_running = NULL
-----------------------------------------------
Update on wois_alarm (cost=0.00..195818.24 rows=9137124 width=66) (actual time=1521513.291..1521513.291 rows=0 loops=1)
Buffers: shared hit=139188764 read=601177 dirtied=751354 written=48382
-> Seq Scan on wois_alarm (cost=0.00..195818.24 rows=9137124 width=66) (actual time=0.009..37118.155 rows=9137124 loops=1)
Buffers: shared hit=546 read=103901 written=48382
Planning time: 0.182 ms
Execution time: 1521523.794 ms
Si mes calculs sont corrects, ça fait une moyenne de 6.7 Mo/s en lecture séquentielle, ce qui est très très peu.
Et du coup... (désolé pour ignorance) c'est bien / pas bien ? optimisable ?
D'où le fait qu'il est préférable d'exécuter ceci :
UPDATE wois_alarm SET engine_running = NULL WHERE engine_running IS NOT NULL:ce qui vous avait été d'ailleurs déjà suggéré.
Oui tout à fait, mais j'avais voulu voir la différence de performance à requête égale avant et après VACUUM
Par contre, après voir lancé le dernier UPDATE wois_alarm SET engine_running = NULL (qui était déjà pourtant à NULL auparavant),
et bien le SELECT COUNT(*) à pris de nouveau plus de temps :
1ère fois : 1 mn 40
2ème fois : 22 s
3ème fois : 52 s
4ème fois : 1 mn 25
5ème fois : 2 mn 02
J'en découvre des choses, mais c'est à n'y rien comprendre !
J'essaierai à nouveau demain avec EXPLAIN (ANALYZE,BUFFERS)
Effectivement,
l'administrateur réseau vient de multiplier par 2 l'espace disque :
=> lancement de la requête SELECT COUNT(*) FROM wois_alarm : temps d'exécution = 2 mn 30
=> exécution de VACUUM FULL wois_alarm, puis à nouveau SELECT COUNT(*) : temps d'exécution = 1.5 s
quelle différence !!!
Par contre pour l'UPDATE global, on passe de 35mn à 23mn
J'ai un peu l'impression (étant donné le nombre de blocs lus par rapport au nombre de blocs écrits) que cette table est très fortement fragmentée. Il serait bon de le vérifier et de faire, le cas échéant, un "VACUUM FULL wois_alarm". Ensuite, pour éviter que cette fragmentation revienne rapidement, il serait préférable de modifier le UPDATE ainsi :
UPDATE wois_alarm SET engine_running = NULL WHERE engine_running IS NOT NULL;
Merci.
J'ai un échec au bout de 30 s après avoir lancé VACUUM FULL wois_alarm :
********** Erreur **********
État SQL :53100
Je vais me rapprocher de l'administrateur réseau et voir avec lui si l'espace disque est suffisant ...
A suivre
Bonjour,
vous avez un buffers shared hit très bas ce qui signifie que les blocs ne sont pas dans la RAM (normal lors d'une première exécution).
Si vous relancez le count(*) encore vous devriez voir le shared it monter.
---------------------------------------------------------------------------------------------------------------------------------
Merci.
J'ai relancé 3 fois la requête, et voici ci dessous le plan d'exécution :
Par contre, j'ai lancé 2 fois également la requête simple, sans ANALYSE. première fois : 2mn30, 2eme fois : 4mn30
---------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=382218.92..382218.94 rows=1 width=0) (actual time=252857.729..252857.730 rows=1 loops=1)
Buffers: shared hit=403 read=248113
-> Seq Scan on wois_alarm (cost=0.00..355478.34 rows=10696234 width=0) (actual time=0.045..244720.972 rows=9137124 loops=1)
Buffers: shared hit=403 read=248113
Planning time: 0.104 ms
Execution time: 252857.828 ms
---------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=382218.92..382218.94 rows=1 width=0) (actual time=230953.724..230953.725 rows=1 loops=1)
Buffers: shared hit=435 read=248081"
-> Seq Scan on wois_alarm (cost=0.00..355478.34 rows=10696234 width=0) (actual time=11.246..222865.570 rows=9137124 loops=1)
Buffers: shared hit=435 read=248081
Planning time: 0.204 ms
Execution time: 230953.779 ms
---------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=382218.92..382218.94 rows=1 width=0) (actual time=294853.451..294853.452 rows=1 loops=1)
Buffers: shared hit=467 read=248049
-> Seq Scan on wois_alarm (cost=0.00..355478.34 rows=10696234 width=0) (actual time=9.563..286475.286 rows=9137124 loops=1)
Buffers: shared hit=467 read=248049
Planning time: 0.095 ms
Execution time: 294853.512 ms
Suite à mon précédent post, voici le plan d'exécution de la requête UPDATE. Merci d'avance si vous avez des idées pour l'optimisation de l'une ou l'autre de ces 2 requêtes.
----------------------------------------------------------------------
EXPLAIN (ANALYZE,BUFFERS) UPDATE wois_alarm SET engine_running = NULL
----------------------------------------------------------------------
Update on wois_alarm (cost=0.00..360587.79 rows=11207179 width=66) (actual time=2429124.370..2429124.370 rows=0 loops=1)
Buffers: shared hit=142222858 read=797052 dirtied=799067 written=70549
-> Seq Scan on wois_alarm (cost=0.00..360587.79 rows=11207179 width=66) (actual time=219.224..175874.781 rows=9137124 loops=1)
Buffers: shared hit=52 read=248464 written=70541
Planning time: 0.279 ms
Execution time: 2429134.392 ms
Bonjour. Tout d'abords merci à tous pour le temps passé à me répondre et pour le partage de vos connaissance.
Voici le plan d'exécution de la requête dont le temps d'exécution me surprends le plus (un simple COUNT). Je posterai ensuite celui de la requête UPDATE dès que s'affichera le résultat.
--------------------------------------------------------------------------------
EXPLAIN (ANALYZE,BUFFERS) SELECT COUNT(*) FROM wois_alarm
--------------------------------------------------------------------------------
Aggregate (cost=388605.74..388605.75 rows=1 width=0) (actual time=248381.319..248381.320 rows=1 loops=1)
Buffers: shared hit=650 read=247866
-> Seq Scan on wois_alarm (cost=0.00..360587.79 rows=11207179 width=0) (actual time=116.003..240159.673 rows=9137124 loops=1)
Buffers: shared hit=650 read=247866
Planning time: 1.276 ms
Execution time: 248381.388 ms
Bonjour,
Merci beaucoup pour vos réponses !
J'ai surtout été surpris de la requête qui a pris 3 mn : SELECT count(*) FROM wois_alarm
on dirait qu'il faut plus de temps pour compter que pour trier !
Sébastien :
Voici à ma connaissance la configuration :
- shared_buffers = 128MB
- ressources de la machine virtuelle : 4GB, 2CPU
Daniel :
la table comporte plusieurs index en effet.
mais le champs qui a fait l'objet de l'update est un boolean, sans index
pour le facteur de remplissage, il n'y a rien de personnalisé. le réglage de l'auto vacuum est celui par défaut
Bonjour,
Je suis tout nouveau sur ce forum, et vous remercie à l'avance de l'éclairage que vous pourrez peut-être m'apporter. voici mon problème par rapport à un temps d'exécution que je trouve beaucoup trop long:
Sur une table qui compte environ 9 millions de lignes, et une dizaine de colonnes,
il a fallu 35 minutes pour exécuter : UPDATE wois_alarm SET engine_running = NULL;
et il a fallu 3 mn 30s pour effectuer : SELECT count(*) FROM wois_alarm;
Est-ce que ça vous parait normal ? Je n'ai pas de point de comparaison pour la durée d'exécution, étant donné que je n'avais jamais effectué un traitement massif sur cette table.
Merci d'avance !
Pages : 1
