Inspiracja , wiedza , realizacja
Jsystems

W przebudowie

Login



Java

Oracle

Linux

Android

PostgreSQL

Microsoft SQL Server

Logowanie wolnych zapytań

Data dodania: Jun 16, 2016
Data aktualizacji: Jun 16, 2016

Możemy znać dziesiątki technik optymalizacyjnych, ale co nam po tym jeśli nie wiemy wobec jakich zapytań je stosować? W ramach tego artykułu ustawimy taką konfigurację, aby wszystkie zapytania których czas wykonania przekroczy wskazaną wartość pojawiały nam się w logu. Ponadto zadbamy o to aby widzieć które zapytania tworzą pliki tymczasowe na dysku (np. podczas sortowania) i jakiej wielkości są te pliki, które zapytania czekają z powodu blokad.


Ustawienie logowania do jednego pliku


W domyślnej konfiguracji logi są zrzucane do 7 plików w katalogu $PGDATA/pg_log, po jednym dla każdego dnia tygodnia które są rotacyjnie nadpisywane. Jeśli chciałbyś mieć log swojego serwera cały czas na podglądzie to nie jest to najbardziej wygodne rozwiązanie. Zaczniemy więc od takiego ustawienia, które sprawi że wszystkie logi będą lądowały w jednym pliku.

Wyedytuj plik postgresql.conf i odnajdź parametr log_filename. Ten parametr określa nazwę pliku logów. Domyślnie w tej nazwie występuje zmienna %D która to właśnie sprawia że dla każdego dnia tygodnia powstaje nowy plik logów. Usuń tę zmienną, bądź w ogóle zmień nazwę pliku na inną:


Aby opcja ta zaczełą działać musimy przeładować konfigurację:

psql -U postgres -d zlecenia -c "select pg_reload_conf()";



Oczywiście zmień nazwę bazy danych na swoją :) Po tym zabiegu powinien nam powstać nowy plik logów w katalogu pg_log:



aby uruchomić jego podgląd wystarczy wykorzystać narzędzie tail:


tail -f /var/lib/pgsql/9.4/data/pg_log/postgresql-wszystko.log



Ustawienia logowania


Wszystkie parametry dotyczące logowania znajdują się w pliku postgresql.conf, tak więc otwórz go ulubionym edytorem. Będziemy zmieniać 4 parametry:

log_min_duration_statement

log_line_prefix

log_lock_waits

log_temp_files


LOG_MIN_DURATION_STATEMENT


Jak opisałem to na początku – będziemy logować wystąpienia zapytań trwających dłużej niż wskazany czas. Należałoby więc ten czas wskazać i robimy to właśnie z użyciem tego parametru. Jego wartość jest wyrażana w milisekundach. Ja ustawiłem na sekundę – czyli 1000 milisekund.



LOG_LINE_PREFIX


Wpisy w logach będą domyślnie zawierały tylko czas wykonania zapytania, a my je sobie wzbogacimy o dodatkowe informacje. Ten parametr określa właśnie jakie mają to być informacje.

Ja ustawiam parametry %t, %a, %u, %d i %r. Oznaczają one logowanie kolejno: moment uruchomienia zapytania, aplikacja która je uruchamia, użytkownika bazodanowego, nazwę bazy na której jest wykonane zapytanie, host kliencki z którego zapytanie zostało uruchomione.



Przykładowy fragment prefiksu wygenerowany w wyniku w.w ustawień:




LOG_LOCK_WAITS i LOG_TEMP_FILES


LOG_LOCK_WAITS to parametr którego włączenie spowoduje logowanie zapytań które musiały oczekiwać na wykonanie w związku z założoną blokadą na obiektach, niezależnie od czasu zapytania i ustawień parametru log_min_duration_statement.

Ustawienie parametru log_temp_files spowoduje logowanie zapytań które w związku z wykonaniem zapytania utworzyły pliki tymczasowe na dysku. Ustawienie go na 0 spowoduje logowanie każdego zapytania które utworzy taki plik, na wartość >0 tylko tych zapytań które utworzą plik o wielkości większej niż podana wartość (w kilobajtach). Ustawienie na -1 wyłącza logowanie takich zapytań. Warto jest mieć tę opcję włączoną, ponieważ takie pliki są wytwarzane w związku np. z sortowaniem i ich pojawienie się jest sygnałem dla administratora że trzeba zwiększyć wartość parametru work_mem, ponieważ sortowanie z użyciem dysku drastycznie spowalnia zapytania.




Aby zmiany parametrów obowiązywały należy jeszcze przeładować konfigurację:


psql -U postgres -d zlecenia -c "select pg_reload_conf()";


Przeglądanie logów


Poniżej przykład wpisów w logu jakie pojawiają się w wyniku ustawienia wymienionych wcześniej ustawień: 


 


Jest jeszcze parametr debug_print_plan który umożliwia logowanie również planów wykonywanych zapytań, ale format wyświetlania jest tak nieczytelny że znacznie wygodniej jest zweryfikować plany wykonań „ręcznie".