![\"\"](\"https:\/\/explainit.pl\/wordpress\/wp-content\/uploads\/2021\/01\/mvcc_diagram.png\")
<\/p>\n\n\n\nPoniewa\u017c powr\u00f3t do podstaw nikomu jeszcze nie zaszkodzi\u0142, to proponujemy dzi\u015b ma\u0142e repetytorium z zakresu MVCC i operacji Vacuum. Pami\u0119tamy, \u017ce PostgreSQL jest oczywi\u015bcie systemem transakcyjnym, wspieraj\u0105cym tradycyjne w\u0142asno\u015bci ACID dla transakcji realizowanych przez aplikacje u\u017cytkownik\u00f3w. W celu prawid\u0142owej realizacji izolacji transakcji, PostgreSQL stosuje technik\u0119 MVCC (Multiversion Concurrency Control), w ramach kt\u00f3rej ka\u017cda modyfikacja rekordu przyczynia si\u0119 do powstania jego nowego obrazu, podczas gdy dotychczasowy obraz rekordu jest pozostawiany w tabeli na potrzeby innych transakcji w toku. W podobny spos\u00f3b, z usuni\u0119cie rekordu wi\u0105\u017ce si\u0119 faktycznym pozostawieniem jego starego obrazu dla innych, odizolowanych transakcji. Nieprzyjemnym skutkiem implementacji MVCC w PostgreSQL jest pozostawianie starych obraz\u00f3w rekord\u00f3w w bazie danych nawet ju\u017c po zako\u0144czeniu innych, potencjalnie zainteresowanych transakcji (wzgl\u0119dy wydajno\u015bciowe). Te stare obrazy nazywamy wtedy „martwymi rekordami” (dead tuples), poniewa\u017c s\u0105 one ca\u0142kowicie zb\u0119dne. Aby martwe rekordy nie powodowa\u0142y nadmiernego marnowania przestrzeni dyskowej i wydajno\u015bci zapyta\u0144, powinny by\u0107 okresowo „sprz\u0105tane” poprzez wykonywanie operacji Vacuum. Manualnie lub automatycznie, przez systemowy proces Autovacuum.<\/p>\n\n\n\n
Poni\u017cszy rysunek pokazuje rzeczywisty przebieg tych operacji na poziomie dyskowym.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
W kroku (1) u\u017cytkownik wstawia sze\u015b\u0107 nowych rekord\u00f3w do tabeli \u2013 rekordy te s\u0105 zapisywane do kolejnych blok\u00f3w pliku tabeli tak, aby ka\u017cdy blok wype\u0142ni\u0107 maksymalnie (lub do poziomu ograniczanego parametrem FILLFACTOR), ale jednocze\u015bnie nie „\u0142ama\u0107” rekordu pomi\u0119dzy dwa bloki. W naszym przyk\u0142adzie blok 0 zosta\u0142 wype\u0142niony ca\u0142kowicie, a w bloku 1 pozostaje jeszcze sporo wolnego miejsca. Nast\u0119pnie, w kroku (2), u\u017cytkownik dokonuje modyfikacji rekordu ROW_2. Zgodnie z implementacj\u0105 mechanizm\u00f3w MVCC, oryginalny rekord ROW_2 nie ulegnie modyfikacji, lecz zamiast tego, zostanie on zdublowany i to na dublecie zostanie zrealizowana modyfikacja zlecona przez u\u017cytkownika. PostgreSQL spr\u00f3buje umie\u015bci\u0107 dublet rekordu ROW_2 w tym samym bloku, w kt\u00f3rym znajduje si\u0119 orygina\u0142, ale je\u017celi ilo\u015b\u0107 wolnego miejsca b\u0119dzie niewystarczaj\u0105ca (to nasz przypadek), wtedy z konieczno\u015bci zapisze go w innym bloku. Mamy teraz do czynienia z dwiema kopiami rekordu ROW_2 \u2013 star\u0105 i aktualn\u0105. Gdy po pewnym czasie stary obraz rekordu ROW_2 nie b\u0119dzie ju\u017c potrzebny \u017cadnej innej transakcji w systemie, stanie si\u0119 on martwym rekordem. Z podobnym zjawiskiem mamy do czynienia w kroku (3), gdzie u\u017cytkownik usuwa rekord ROW_4. Rekord ten stanie si\u0119 martwy, ale wci\u0105\u017c b\u0119dzie znajdowa\u0107 si\u0119 na dysku. Zauwa\u017cmy, \u017ce w tym momencie, tabela formalnie zawiera pi\u0119\u0107 rekord\u00f3w, ale w jej blokach znajduje si\u0119 rekord\u00f3w siedem \u2013 w\u015br\u00f3d nich dwa martwe, zajmuj\u0105ce przestrze\u0144 dyskow\u0105 i pogarszaj\u0105ce wydajno\u015b\u0107 operacji typu Seq Scan. W celu pozbycia si\u0119 martwych rekord\u00f3w, administrator lub proces Autovacuum wykonuje w kroku (4) operacj\u0119 Vacuum, kt\u00f3ra przetwarza wszystkie bloki pliku danych tabeli i fizycznie wymazuje wszystkie martwe rekordy (na podstawie identyfikator\u00f3w transakcji). Operacja Vacuum dokonuje te\u017c reorganizacji rekord\u00f3w w obr\u0119bie blok\u00f3w tak, aby defragmentowa\u0107 powsta\u0142e wolne miejsce. Nie dokonuje jednak globalnej defragmentacji wolnej przestrzeni. Na to pozwala nam opcjonalna operacja Vacuum Full (krok (5)), kt\u00f3ra opr\u00f3cz eliminacji martwych rekord\u00f3w, optymalizuje te\u017c fizyczn\u0105 organizacj\u0119 rekord\u00f3w w pliku danych (przepisuje rekordy do nowego pliku, stary usuwa). Ze wzgl\u0119du na czasoch\u0142onno\u015b\u0107 i inwazyjno\u015b\u0107 (blokada wy\u0142\u0105czna na ca\u0142ej tabeli), operacja Vacuum Full stosowana jest do\u015b\u0107 rzadko.<\/p>\n\n\n\n
Aby przekona\u0107 si\u0119, czy naszym tabelom nie dolega problem nadmiernej liczby martwych rekord\u00f3w, wynikaj\u0105cy na przyk\u0142ad z niew\u0142a\u015bciwej konfiguracji procesu Autovacuum, mo\u017cemy monitorowa\u0107 ich liczb\u0119, pos\u0142uguj\u0105c si\u0119 jednym z poni\u017cszych zapyta\u0144:<\/p>\n\n\n\n
select relname, pg_stat_get_live_tuples(c.oid), pg_stat_get_dead_tuples(c.oid) from pg_class c;<\/pre>\n\n\n\nselect relname, n_live_tup, n_dead_tup from pg_stat_user_tables;<\/pre>\n","protected":false},"excerpt":{"rendered":"