Coupons le vide?! Alexey Lesovsky

Décodage du rapport 2018 par Alexei Lesovsky "Coupons le vide?!"

Note de l'éditeur: toute recommandation de modification des paramètres doit toujours être comparée dans d'autres rapports.

Un tel appel se produit souvent lorsque des problèmes surviennent dans PostgreSQL, et le principal suspect est vacuum(ci-après simplement «vide»). Par expérience, beaucoup marchent sur ce râteau, et mes collègues de Data Egret et moi devons souvent en tirer les conséquences, car alors tout empire. Mais si vous faites attention au vide lui-même, alors, peut-être, il n'y a pas une telle personne qui utiliserait Postgres, et en même temps ne savait rien de lui. Après tout, l'histoire du vide commence il y a relativement longtemps, et sur Internet, vous pouvez trouver beaucoup de messages anciens et nouveaux sur le vide, des discussions volumineuses sur les listes de diffusion. Malgré le fait que le sujet du vide soit décrit en détail dans la documentation officielle de PostgreSQL, de nouveaux articles et de nouvelles discussions continueront d'apparaître. C'est peut-être pourquoi beaucoup de mythes, contes, histoires d'horreur et idées fausses sont associés au vide. Pendant ce temps, le vide est l'un des composants les plus importants de PostgreSQL,et son travail affecte directement la productivité. Il est impossible de tout dire sur le vide dans un seul rapport, mais je voudrais révéler les points clés liés au vide, tels que sa structure interne, les approches de base de son réglage, la surveillance des performances, la surveillance et ce qu'il faut faire lorsque le vide est la chose principale suspect de tous les ennuis. Eh bien, et, bien sûr, je veux dissiper les mythes courants et les idées fausses associés au vide.Je veux dissiper les mythes courants et les idées fausses associés au vide.Je veux dissiper les mythes courants et les idées fausses associés au vide.

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

, , , . , . , , , .

, , ?

: « , . - . , ».

? , . , , , – 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 . , , , , . . . - – . .

, . - ?

Il existe des fonctions distinctes dans le code postgres qui collectent des statistiques sur la distribution des données dans les tableaux. Il s'agit d'un sous-système autovacuum séparé. Il lit des exemples de données de taille limitée dans le tableau. Et sur la base de cela, construit la distribution en fonction des données. Et il enregistre ces informations dans le catalogue système pg_statisticou dans la vue système pg_stats. Et lorsque le planificateur crée des plans de requête, il lit les informations de ce répertoire. Et sur sa base fait des plans. Et puis il choisit le meilleur.