La pregunta clàssica que un desenvolupador porta al seu DBA o un propietari d'una empresa a un consultor de PostgreSQL gairebé sempre sona igual: "Per què les sol·licituds triguen tant a completar-se a la base de dades?"
Conjunt tradicional de motius:
- algorisme ineficient
quan decideixes UNIR-TE a diversos CTE en un parell de desenes de milers de registres - estadístiques obsoletes
si la distribució real de les dades de la taula ja és molt diferent de la recollida per ANALYZE la darrera vegada - "connectar" als recursos
i ja no hi ha prou potència de càlcul dedicada de la CPU, gigabytes de memòria s'estan bombejant constantment o el disc no pot mantenir-se al dia amb tots els "desitjos" de la base de dades. - bloqueig de processos competitius
I si els bloquejos són bastant difícils d'atrapar i analitzar, llavors per a tota la resta necessitem pla de consulta, que es pot obtenir utilitzant (És millor, per descomptat, EXPLICAR de seguida (ANALITZAR, BUFFERS)...) o .
Però, com s'indica a la mateixa documentació,
"Entendre un pla és un art, i dominar-lo requereix una certa experiència..."
Però podeu prescindir-ne si feu servir l'eina adequada!
Com és normalment un pla de consultes? Alguna cosa així:
Index Scan using pg_class_relname_nsp_index on pg_class (actual time=0.049..0.050 rows=1 loops=1)
Index Cond: (relname = $1)
Filter: (oid = $0)
Buffers: shared hit=4
InitPlan 1 (returns $0,$1)
-> Limit (actual time=0.019..0.020 rows=1 loops=1)
Buffers: shared hit=1
-> Seq Scan on pg_class pg_class_1 (actual time=0.015..0.015 rows=1 loops=1)
Filter: (relkind = 'r'::"char")
Rows Removed by Filter: 5
Buffers: shared hit=1o així:
"Append (cost=868.60..878.95 rows=2 width=233) (actual time=0.024..0.144 rows=2 loops=1)"
" Buffers: shared hit=3"
" CTE cl"
" -> Seq Scan on pg_class (cost=0.00..868.60 rows=9972 width=537) (actual time=0.016..0.042 rows=101 loops=1)"
" Buffers: shared hit=3"
" -> Limit (cost=0.00..0.10 rows=1 width=233) (actual time=0.023..0.024 rows=1 loops=1)"
" Buffers: shared hit=1"
" -> CTE Scan on cl (cost=0.00..997.20 rows=9972 width=233) (actual time=0.021..0.021 rows=1 loops=1)"
" Buffers: shared hit=1"
" -> Limit (cost=10.00..10.10 rows=1 width=233) (actual time=0.117..0.118 rows=1 loops=1)"
" Buffers: shared hit=2"
" -> CTE Scan on cl cl_1 (cost=0.00..997.20 rows=9972 width=233) (actual time=0.001..0.104 rows=101 loops=1)"
" Buffers: shared hit=2"
"Planning Time: 0.634 ms"
"Execution Time: 0.248 ms"Però llegir el pla al text "del full" és molt difícil i poc clar:
- es mostra al node suma per recursos de subarbre
és a dir, per entendre quant de temps va trigar a executar un node en particular, o quant exactament aquesta lectura de la taula va generar dades del disc, cal restar d'alguna manera una de l'altra. - el temps del node és necessari multiplicar per bucles
Sí, la resta no és l'operació més complexa que s'ha de fer "al cap"; després de tot, el temps d'execució s'indica com la mitjana d'una execució d'un node i n'hi pot haver centenars. - bé, i tot plegat ens impedeix respondre a la pregunta principal: doncs, qui "l'enllaç més feble"?
Quan vam intentar explicar tot això a diversos centenars dels nostres desenvolupadors, ens vam adonar que des de fora semblava una cosa així:
I això vol dir que necessitem...
Eina
En ell hem intentat recollir totes les mecàniques clau que ajuden a entendre “qui té la culpa i què fer” segons el pla i la petició. Bé, i comparteix part de la teva experiència amb la comunitat.
Coneix i utilitza -
Visibilitat dels plànols
És fàcil entendre el pla quan es veu així?
Seq Scan on pg_class (actual time=0.009..1.304 rows=6609 loops=1)
Buffers: shared hit=263
Planning Time: 0.108 ms
Execution Time: 1.800 ms
De debò.
Però així, en forma abreujadaquan els indicadors clau estan separats, és molt més clar:
Però si el pla és més complicat, vindrà al rescat distribució temporal de gràfics circulars per nodes:
Bé, per a les opcions més difícils té pressa per ajudar gràfic de progrés:
Per exemple, hi ha situacions força no trivials en què un pla pot tenir més d'una arrel real:
Pistes estructurals
Bé, si tota l'estructura del pla i els seus punts dolorosos ja estan distribuïts i visibles, per què no els ressalten al desenvolupador i els expliquen en "idioma rus"?
Ja hem recollit un parell de dotzenes de plantilles de recomanació.
Perfilador de consultes línia per línia
Ara, si superposeu la consulta original al pla analitzat, podeu veure quant de temps s'ha dedicat a cada declaració individual, una cosa així:
...o fins i tot així:
Substitució de paràmetres en una sol·licitud
Si heu "adjuntat" no només una sol·licitud al pla, sinó també els seus paràmetres des de la línia DETALLS del registre, també podeu copiar-la en una de les opcions:
- amb substitució de valors a la consulta
per a l'execució directa a la vostra base i un perfil addicionalSELECT 'const', 'param'::text; - amb substitució de valors mitjançant PREPARE/EXECUTE
per emular el treball del planificador, quan es pot ignorar la part paramètrica, per exemple, quan es treballa en taules particionadesDEALLOCATE ALL; PREPARE q(text) AS SELECT 'const', $1::text; EXECUTE q('param'::text);
Arxiu de plànols
Enganxa, analitza, comparteix amb els companys! Els plànols romandran arxivats i podreu tornar-hi més endavant:
Però si no voleu que altres persones vegin el vostre pla, no us oblideu de marcar la casella "no publicar a l'arxiu".
En els següents articles parlaré de les dificultats i decisions que sorgeixen a l'hora d'analitzar un pla.
Font: www.habr.com