ÂżVamos a apagar el vacĂ­o? Alexey Lesovsky

DecodificaciĂłn del informe de 2018 de Alexei Lesovsky "ÂżVamos a apagar el vacĂ­o?"


Nota del editor: cualquier recomendación para cambiar los parámetros siempre debe compararse en otros informes.


Tal llamada a menudo surge cuando surgen problemas en PostgreSQL, y el principal sospechoso es vacuum(en adelante, simplemente "vacío"). Por experiencia, muchos están pisando este rastrillo, y mis colegas de Data Egret a menudo tienen que analizar las consecuencias, porque entonces todo empeora. Pero si prestas atención al vacío en sí, entonces, tal vez, no existe esa persona que usaría Postgres, y al mismo tiempo no sabía nada de él. Después de todo, la historia del vacío comienza hace relativamente tiempo, y en Internet puede encontrar muchas publicaciones antiguas y nuevas sobre el vacío, voluminosas discusiones en las listas de correo. A pesar de que el tema del vacío se describe en detalle en la documentación oficial de PostgreSQL, continuarán apareciendo nuevas publicaciones y nuevas discusiones. Quizás es por eso que muchos mitos, cuentos, historias de terror y conceptos erróneos están asociados con el vacío. Mientras tanto, el vacío es uno de los componentes más importantes de PostgreSQL,y su trabajo afecta directamente la productividad. Es imposible contar absolutamente todo sobre el vacío en un informe, pero me gustaría revelar puntos clave relacionados con el vacío, como su estructura interna, los principales enfoques para su ajuste, monitoreo del rendimiento, monitoreo y qué hacer cuando el vacío es lo principal. sospechoso de todos los problemas. Bueno, y, por supuesto, quiero disipar mitos comunes y conceptos erróneos asociados con el vacío.Quiero disipar mitos comunes y conceptos erróneos asociados con el vacío.Quiero disipar mitos comunes y conceptos erróneos asociados con el vacío.




! . : , . , . , . , - , .



, , , . , . , , , .



, , ?



: « , . - . , ».


? , . , , , – 100 % ( ). , . - .



, . postgres’ . , . , . , . . - .



, . - , , , . . .



- / : « , ». , . - .



, , , iotop , . - . . .


. . , .



? , - . . . .



- - : « . – autovacuum. ».



, , , : , . . .


, .


  • ( DBA) – , . , . , .
  • , . . . .
  • , shared buffers, ( , ), . . - , shared buffers.
  • . . – .


. . : https://github.com/lesovsky/ConferenceStuff/tree/master/2016.highload


? pgbench . pgbench . . , . . . , .



. , . , , , - . , Postgres, ( , ). , .



, MVCC.


MVCC (Multi-Version Concurrency Control) – "" , Postgres', . . .


  • . . .
  • .
  • , ; ( ).


? . . (snapshot).



: , . , ( COMMIT ROLLBACK).



COMMIT, , . , " ". : PostgreSQL.


. , . - , «delete», «update». .. "" — dead tuples.



. – xmin. , . . . insert, xmin .


, . xmax , .


delete. . — xmax , .


, "" . , xmax . — , Postgres , . - - , .. , .



, ? , , , .


. , . .



«delete», «update» , / . , , - .



, . .



, , , . .



:


  • , , , "", , .
  • shared buffers .
  • bloat , .. — .


. ?


  • -, .
  • Postgres, . . . , , - , .
  • . . .
  • – . . . , .


  • - . , Postgres . , . , .
  • , .
  • , . 32 , . 4294967296. , . , , ( ). .. to prevent wraparound vacuum, . wraparound vacuum — .
  • , , . - . . . , . , .


  • . Postgres , Postgres , , Pentium, - , . - . , , , , - . . .
  • Postgres . . 9.6. , 9.6 , 9.6. ( , Postgres 12)


- . .



-, , .. — cost-based vacuum. .


, : . , ( ) — . .


, . .


. vacuum_cost_page_hit, vacuum_cost_page_miss, vacuum_cost_page_dirty, hit, miss, dirty.


Hit – , , shared buffers, . . . , .


Miss – shared buffers . . , . , shared buffers, (page cache) - . , .


Dirty – , , . .


. vacuum_cost_limit. .


vacuum_cost_delay. , cost limit . cost delay .


, , , . . .



-, . - , , .


  • , 32 , . , , autovacuum_max_workers 10-15 % .
  • autovacuum_naptime. , . 60 . . , 1 . , . , – . . . . , .
  • – , vacuum_cost_limit, , , . , vacuum_cost_limit .


-, , . , . – .


. autovacuum_vacuum_scale_factor. scale factor . - scale_factor 0.2, . . 20 %.


autovacuum_vacuum_threshold. - – 50 . , , .



, - 20 %. , autovacuum_vacuum_threshold , , 1-2-5 %.



, autovacuum_vacuum_scale_factor . . , 1 % — . autovacuum_vacuum_scale_factor 0. autovacuum_vacuum_threshold, . . , , . autovacuum_vacuum_scale_factor , autovacuum_vacuum_threshold.



, . 4-5 , HDD , . HDD . , , . , , , .


SSD . SSD . , .


SSD . , . , (, ), . – , .


NVMe , , . I/O . , . , - – - . , IO, , .



- . vacuum_cost_delay vacuum_cost_limit. . . . . . . – . .


, . , , .



vacuum_cost_delay = 0
vacuum_cost_page_hit = 0
vacuum_cost_page_miss = 5
vacuum_cost_page_dirty = 5
vacuum_cost_limit = 200
--
autovacuum_max_workers = 10
autovacuum_naptime = 1s
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.05
autovacuum_vacuum_cost_delay = 5ms
autovacuum_vacuum_cost_limit = -1

SSD , . , , .


: SSD.



. - , - "" , .


, storage parameters. tablespaces, . , .



, — , , , Postgres. , , pgcompacttable pg_repack.


bloat .


, , . – , ( ). .



, . - .


Postgres , , .


pg_stat_activity. , (view) , , .


, , , . . . pg_stat_atctivity ().



, , . , prevent wraparound . (autovacuum_max_workers)– .


– . , , , . — . .



, , pg_stat_progress_vacuum 9.6. .


, , . pg_stat_activity , , , , pg_stat_progress_vacuum .



https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/vacuum_activity.sql


, , , . , 50 % . 3 , 3 .


— : , . , .



:


  • . .
  • . cost-based, cost-.
  • – . , , .


! ! . 9.6 , . , , , . - ? , - ?


. 9.6 freeze-, . postgres’ , wraparound vacuum. , . , , . , , . , 9.5 . , . , .


, buffer cache, read?


, autovacuum worker , buffer-. 32 , -. , .


?


, , buffer cache, page cache, , . . , page cache, shared buffers .


, ! , . , . time . 5 1 , . . , 5 100 % CPU, storage. .


– . – . CPU, - . – ? Ubuntu. Ubuntu powersave. . ., , 3,4 GHz, – 1,2. . performance . . , , , , , , . , , .


. , , . . - , . - bloat - , . .


! , . : . - autovacuum_vacuum_scale_factor autovacuum_vacuum_threshold . , , , . , naptime , analyze. Postgres . pg_class reltuples


.


. .


.


dead tuples community , 2ndQuadrant. – . analyze reltuples .


, . – . . , «idle in transactions», , . - . , . . , .


, ?


, MVCC . - , .


reltuples?


. .


( ) . , . : update, insert . . : , . tuples. .


, . . , . . reltuples . , , , , . . . - – . .


, . - ?


Hay funciones separadas en el código de postgres que recopilan estadísticas sobre la distribución de datos dentro de las tablas. Este es un subsistema de vacío automático separado. Lee datos de muestra de tamaño limitado de la tabla. Y sobre la base de esto construye la distribución de acuerdo con los datos. Y guarda esta información en el catálogo del sistema pg_statistico en la vista del sistema pg_stats. Y cuando el planificador crea planes de consulta, lee información de este directorio. Y sobre su base hace planes. Y luego elige el mejor.


All Articles