Wprowadzenie do auto_explain:Jak automatycznie rejestrować wolne plany zapytań Postgres

Czy chcesz wiedzieć, dlaczego zapytanie PostgreSQL jest wolne? W takim razie EXPLAIN ANALYZE to świetny punkt wyjścia. Jednak plany zapytań mogą zależeć od innych działań serwera, ich uruchomienie może zająć trochę czasu i mogą się zmieniać w czasie, więc jeśli chcesz zobaczyć rzeczywiste plany wykonania najwolniejszych zapytań, narzędzie auto_explain jest narzędziem, którego potrzebujesz. W tym poście przyjrzymy się, co robi, jak go skonfigurować i jak używać tych dzienników, aby przyspieszyć zapytania.

Co to jest auto_explain?

auto_explain to rozszerzenie PostgreSQL, które umożliwia rejestrowanie planów zapytań dla zapytań wolniejszych niż (konfigurowalny) próg. Jest to niezwykle przydatne do debugowania powolnych zapytań, zwłaszcza tych, które tylko czasami są problematyczne. Jest to jeden z modułów, dzięki czemu można go łatwo zainstalować i skonfigurować na zwykłym PostgreSQL i jest tak użyteczny, że domyślnie jest włączony w ScaleGrid.

Ogromne podziękowania dla Takahiro Itagaki, głównego autora pierwszej wersji auto_explain (zatwierdzenie, wątek), Deana Rasheeda, którego pierwsza łatka i sugestia była oparta, oraz wielu współtwórcy i recenzenci od tego czasu.

Których parametrów auto_explain mam użyć?

Poniżej omówimy najważniejsze parametry, ale zapoznaj się z poniższą tabelą lub oficjalną dokumentacją, aby uzyskać więcej informacji na temat pełnego zakresu rzeczy, które możesz śledzić.

Najważniejszym parametrem auto_explain jest log_min_duration . Domyślnie jest to ustawione na -1 , co oznacza, że ​​nic nie będzie logowane – więc jeśli chcemy jakieś logi musimy to zmienić! Domyślną jednostką jest ms, więc ustawienie 100 zarejestruje plany zapytań dla wszystkich zapytań, które przekraczają 100 ms. To właśnie wybraliśmy jako domyślne w ScaleGrid, ale można to skonfigurować w Admin -> Config. Jeśli z jakiegoś powodu chcesz rejestrować plan zapytań dla każdego zapytania, możesz ustawić to na 0 – ale uważaj, może to mieć poważne konsekwencje dla wydajności.

Ponieważ zapytania są już wykonywane na serwerze, prawdopodobnie chcesz również włączyć auto_explain.log_analyze . To sprawia, że ​​dane wyjściowe są równoważne uruchomieniu EXPLAIN ANALYZE . Domyślnie oznacza to również, że śledzone są czasy operacji. Wiąże się to z pewnym dodatkowym obciążeniem, które można zminimalizować, wyłączając auto_explain.log_timing (domyślnie włączone z log_analyze ). Oczywiście czasy na operację są bardzo przydatne podczas debugowania wolnych zapytań! Nasze wewnętrzne testy wykazały akceptowalne koszty ogólne, więc jest to domyślnie włączone w ScaleGrid, ale jak zawsze przetestuj obciążenie, aby sprawdzić, czy obciążenie jest akceptowalne w Twoim przypadku. Obecnie dostępne publicznie informacje na ten temat są ograniczone, ale niedawny post zespołu pgMustard pokazał, że przynajmniej przy niewielkim obciążeniu transakcyjnym obciążenie może wynosić zaledwie 2%. Jak zauważyli, można to zmniejszyć za pomocą auto_explain.sample_rate parametr, kosztem śledzenia tylko podzbioru zapytań.

Ostatnim parametrem, który omówimy szczegółowo, jest auto_explain.log_format . Domyślnym wyjściem jest TEKST, który prawdopodobnie najlepiej znasz z używania EXPLAIN .

Oto prosty przykład tego, jak może wyglądać wyjście auto_explain w formacie TEKST:

2021-09-10 15:32:04.606 BST [22770] LOG:  duration: 3184.383 ms  plan:
	Query Text: select * from table1 order by column1;
	Sort  (cost=12875.92..13125.92 rows=100000 width=37) (actual time=2703.799..3055.401 rows=100000 loops=1)
	  Sort Key: column1
	  Sort Method: external merge  Disk: 4696kB
	  Buffers: shared hit=837, temp read=587 written=589
	  ->  Seq Scan on table  (cost=0.00..1834.01 rows=100000 width=37) (actual time=0.033..27.795 rows=100000 loops=1)
	        Buffers: shared hit=834

Widać tutaj, że otrzymujesz czas trwania zapytania na początku, do którego zwykle przywykłeś na końcu planów zapytań. Zobaczysz również tekst zapytania, w tym wszelkie parametry.

Popularne narzędzia do wizualizacji explain.depesz i explain.dalibo, akceptują plany zapytań w formacie TEKSTOWYM, ale oba obsługują również format JSON. Jeśli niektórzy z Twojego zespołu wolą używać narzędzi, takich jak PEV i pgMustard, które obsługują tylko format JSON, możesz ustawić go jako format. W przypadku klientów korzystających ze ScaleGrid zdecydowaliśmy się na format JSON, częściowo dlatego, że chcieliśmy go łatwiej przeanalizować dla naszej własnej funkcji powolnej analizy zapytań.

Oto pełna lista parametrów auto_explain i ich wartości domyślnych:

Instalowanie auto_explain

W ScaleGrid auto_explain jest domyślnie włączone z progiem 100 ms. Możesz to skonfigurować w Administracja -> Konfiguracja.

W waniliowym PostgreSQL możesz zainstalować auto_explain po prostu dodając go do jednej z session_preload_libraries lub shared_preload_libraries . Pierwszy z nich ma zalety a) nie wymaga restartu (ale będzie ładowany tylko w nowych sesjach) oraz b) umożliwia włączenie go tylko dla niektórych użytkowników (poprzez ustawienie tego parametru za pomocą ALTER ROLE SET ).

session_preload_libraries = auto_explain
auto_explain.log_min_duration = 100
auto_explain.log_analyze = true
auto_explain.log_buffers = true
auto_explain.log_format = JSON

LOAD 'auto_explain';