Kluczowe rzeczy do monitorowania w PostgreSQL — analiza obciążenia
W systemach komputerowych monitorowanie to proces zbierania metryk, analizowania, obliczania statystyk oraz generowania podsumowań i wykresów dotyczących wydajności lub pojemności systemu, a także generowania alertów w przypadku nieoczekiwanych problemów lub awarii, które wymagają natychmiastowej uwagi lub działania. Dlatego monitorowanie ma dwa zastosowania:jedno do analizy i prezentacji danych historycznych, które pomagają nam identyfikować średnio- i długoterminowe trendy w naszym systemie, a tym samym pomagają nam planować aktualizacje, a drugie do natychmiastowego działania w przypadku problemów.
Monitorowanie pomaga nam identyfikować problemy i reagować na te problemy w szerokim zakresie dziedzin, takich jak:
- Infrastruktura/sprzęt (fizyczny lub wirtualny)
- Sieć
- Przechowywanie
- Oprogramowanie systemowe
- Oprogramowanie aplikacji
- Bezpieczeństwo
Monitorowanie to główna część pracy administratora baz danych. PostgreSQL jest tradycyjnie znany jako „nie wymagający konserwacji” dzięki swojemu wyrafinowanemu projektowi, a to oznacza, że system może funkcjonować z niską frekwencją w porównaniu z innymi alternatywami. Jednak w przypadku poważnych instalacji, w których kluczowa jest wysoka dostępność i wydajność, system bazy danych musi być regularnie monitorowany.
Rola PostgreSQL DBA może wspinać się na wyższe poziomy w hierarchii firmy, nie tylko czysto techniczne:poza podstawowym monitorowaniem i analizą wydajności, musi być w stanie dostrzec zmiany we wzorcach użytkowania, zidentyfikować możliwe przyczyny, zweryfikować założenia i wreszcie przetłumaczyć ustalenia pod względem biznesowym. Na przykład administrator baz danych musi być w stanie zidentyfikować nagłą zmianę w określonej działalności, która może być powiązana z potencjalnym zagrożeniem bezpieczeństwa. Tak więc rola PostgreSQL DBA jest kluczową rolą w firmie i musi ściśle współpracować z innymi szefami działów w celu identyfikowania i rozwiązywania pojawiających się problemów. Monitorowanie to duża część tej odpowiedzialności.
PostgreSQL udostępnia wiele gotowych narzędzi, które pomagają nam zbierać i analizować dane. Ponadto, ze względu na swoją rozszerzalność, zapewnia środki do opracowywania nowych modułów w systemie podstawowym.
PostgreSQL jest wysoce zależny od systemu (sprzętu i oprogramowania), na którym działa. Nie możemy oczekiwać, że serwer PostgreSQL będzie działał dobrze, jeśli wystąpią problemy w którymkolwiek z istotnych komponentów w pozostałej części systemu. Tak więc rola PostgreSQL DBA pokrywa się z rolą administratora. Poniżej, gdy sprawdzimy, co należy oglądać w monitorowaniu PostgreSQL, napotkamy zarówno zmienne i metryki zależne od systemu, jak i konkretne dane PostgreSQL.
Monitoring nie jest bezpłatny. Firma/organizacja musi w nią włożyć dobrą inwestycję z zaangażowaniem w zarządzanie i utrzymanie całego procesu monitorowania. Dodaje również niewielkie obciążenie serwera PostgreSQL. Nie ma się czym martwić, jeśli wszystko jest poprawnie skonfigurowane, ale musimy pamiętać, że może to być inny sposób na niewłaściwe użycie systemu.
Podstawy monitorowania systemu
Ważnymi zmiennymi w monitorowaniu systemu są:
- Wykorzystanie procesora
- Korzystanie z sieci
- Miejsce na dysku / Wykorzystanie dysku
- Wykorzystanie pamięci RAM
- IOPS dysku
- Zamień użycie miejsca
- Błędy sieciowe
Oto przykład ClusterControl pokazujący wykresy dla niektórych krytycznych zmiennych PostgreSQL pochodzących z pg_stat_database i pg_stat_bgwriter (które omówimy w kolejnych akapitach) podczas dwukrotnego uruchamiania pgbench -c 64 -t 1000 pgbench:
Zauważyliśmy, że w pierwszym uruchomieniu mamy szczyt odczytów bloków, ale podczas drugiego testu zbliżamy się do zera, ponieważ wszystkie bloki znajdują się w shared_buffers.
Inne interesujące zmienne to między innymi aktywność stronicowania, przerwania, przełączanie kontekstu. Istnieje mnóstwo narzędzi do użycia w systemach Linux/BSD i systemach uniksowych lub podobnych do uniksów. Niektóre z nich to:
-
ps:lista uruchomionych procesów
-
top/htop/sysstat:do monitorowania wykorzystania systemu (procesora / pamięci)
-
vmstat:do ogólnego monitorowania aktywności systemu (w tym pamięci wirtualnej)
-
iostat/iotop/top -mio:do monitorowania IO
-
ntop:do monitorowania sieci
Oto przykład vmstat na polu FreeBSD podczas zapytania, które wymaga odczytów dysku, a także pewnych obliczeń:
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id
0 0 0 98G 666M 421 0 0 0 170 2281 5 0 538 6361 2593 1 1 97
0 0 0 98G 665M 141 0 0 0 0 2288 13 0 622 11055 3748 3 2 94
--- query starts here ---
0 0 0 98G 608M 622 0 0 0 166 2287 1072 0 1883 16496 12202 3 2 94
0 0 0 98G 394M 101 0 0 0 2 2284 4578 0 5815 24236 39205 3 5 92
2 0 0 98G 224M 4861 0 0 0 1711 2287 3588 0 4806 24370 31504 4 6 91
0 0 0 98G 546M 84 188 0 0 39052 41183 2832 0 4017 26007 27131 5 7 88
2 0 0 98G 469M 418 0 0 1 397 2289 1590 0 2356 11789 15030 2 2 96
0 0 0 98G 339M 112 0 0 0 348 2300 2852 0 3858 17250 25249 3 4 93
--- query ends here ---
1 0 0 98G 332M 1622 0 0 0 213 2289 4 0 531 6929 2502 3 2 95Powtarzając zapytanie, nie zauważylibyśmy żadnego nowego wzrostu aktywności dysku, ponieważ te bloki dysku byłyby już w pamięci podręcznej systemu operacyjnego. Chociaż administrator PostgreSQL DBA musi być w stanie w pełni zrozumieć, co dzieje się w podstawowej infrastrukturze, w której działa baza danych, bardziej złożone monitorowanie systemu jest zwykle zadaniem administratora systemu, ponieważ jest to duży temat sam w sobie.
W Linuksie bardzo przydatny skrót do góry narzędzie naciska „C”, które przełącza wyświetlanie wiersza poleceń procesów. PostgreSQL domyślnie przepisuje wiersz poleceń backendów z aktualną aktywnością SQL, którą aktualnie wykonują, a także z użytkownikiem.
Podstawy monitorowania PostgreSQL
Ważnymi zmiennymi w monitorowaniu PostgreSQL są:
- Wydajność pamięci podręcznej bufora (trafienia w pamięci podręcznej a odczyty z dysku)
- Liczba zatwierdzeń
- Liczba połączeń
- Liczba sesji
- Punkty kontrolne i statystyki bgwriter
- Odkurzacze
- Zamki
- Replikacja
- I na koniec, ale zdecydowanie nie mniej ważne, zapytania
Zasadniczo w konfiguracji monitorowania istnieją dwa sposoby gromadzenia danych:
- Aby uzyskać dane za pośrednictwem dziennika
- Aby uzyskać dane przez zapytanie systemu PostgreSQL
Pozyskiwanie danych w oparciu o pliki dziennika zależy od (odpowiednio skonfigurowanego) dziennika PostgreSQL. Tego rodzaju rejestrowanie możemy wykorzystać do przetwarzania danych „off-line”. Monitorowanie oparte na plikach dziennika najlepiej sprawdza się, gdy wymagane jest minimalne obciążenie serwera PostgreSQL i kiedy nie zależy nam na danych w czasie rzeczywistym lub otrzymywaniu alertów na żywo (chociaż monitorowanie na żywo przy użyciu danych z pliku dziennika może być możliwe poprzez np. skierowanie dziennika postgresql do sysloga a następnie przesyłanie strumieniowe syslog na inny serwer przeznaczony do przetwarzania logów).
Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokumentZbieracz statystyk PostgreSQL
PostgreSQL zapewnia bogaty zestaw widoków i funkcji łatwo dostępnych za pośrednictwem podsystemu Statistics Collector. Dane te są podzielone na dwie kategorie:
- Dynamiczne informacje o tym, co system robi w tej chwili.
- Statystyki zgromadzone od ostatniego zresetowania podsystemu zbierającego statystyki.
Dynamiczne widoki statystyk podaj informacje o bieżącej aktywności na proces (pg_stat_activity), stanie fizycznej replikacji (pg_stat_replication), stanie fizycznego czuwania (pg_stat_wal_receiver) lub logicznego (pg_stat_subscription), ssl (pg_stat_ssl) i próżni (pg_stat_progress_vacuum).
Wyświetlenia zebranych statystyk dostarczać informacji o ważnych procesach w tle, takich jak archiwizator wal, bgwriter i obiekty bazy danych:tabele użytkowników lub systemowe, indeksy, sekwencje i funkcje, a także same bazy danych.
Powinno być już oczywiste, że istnieje wiele sposobów kategoryzowania danych związanych z monitorowaniem:
- Według źródła:
- Narzędzia systemowe (ps, top, iotop itp.)
- Plik dziennika PgSQL
- Baza danych
- Dynamiczny
- Zebrane
- Według określonej operacji bazy danych:
- Buforowa pamięć podręczna
- Potwierdza
- Zapytania
- Sesje
- Punkty kontrolne
- itd.
Po przeczytaniu tego artykułu i eksperymentowaniu z przedstawionymi pojęciami, koncepcjami i terminami powinieneś być w stanie stworzyć macierz 2D ze wszystkimi możliwymi kombinacjami. Na przykład, konkretną aktywność PostgreSQL (polecenie SQL) można znaleźć za pomocą:ps lub top (narzędzia systemowe), plików dziennika PostgreSQL, pg_stat_activity (widok dynamiczny), ale także za pomocą pg_stat_statements, rozszerzenia znalezionego w contrib (widok zebranych statystyk) . Podobnie informacje o blokadach można znaleźć w plikach dziennika PostgreSQL, pg_locks i pg_stat_activity (przedstawiony tuż poniżej) za pomocą wait_event i wait_event_type . Z tego powodu trudno jest objąć rozległy obszar monitoringu w jednowymiarowy, linearny sposób, a autorowi grozi z tego powodu zamieszanie u czytelnika. Aby tego uniknąć, zajmiemy się monitorowaniem z grubsza, postępując zgodnie z oficjalną dokumentacją i dodając powiązane informacje w razie potrzeby.
Dynamiczne wyświetlenia statystyk
Korzystanie z pg_stat_activity jesteśmy w stanie zobaczyć, jaka jest bieżąca aktywność różnych procesów backendowych. Na przykład, jeśli uruchomimy następujące zapytanie na częściach tabeli z około 3 milionami wierszy:
testdb=# \d parts
Table "public.parts"
Column | Type | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
id | integer | | |
partno | character varying(20) | | |
partname | character varying(80) | | |
partdescr | text | | |
machine_id | integer | | |
parttype | character varying(100) | | |
date_added | date | | |I uruchommy następujące zapytanie, które potrzebuje kilku sekund na ukończenie:
testdb=# select avg(age(date_added)) FROM parts;Otwierając nowy terminal i uruchamiając następujące zapytanie, podczas gdy poprzednie wciąż działa, otrzymujemy:
testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid | 21305
usename | achix
application_name | psql
client_addr |
backend_start | 2018-03-02 18:04:35.833677+02
xact_start | 2018-03-02 18:04:35.832564+02
query_start | 2018-03-02 18:04:35.832564+02
state | active
backend_xid |
backend_xmin | 438132638
query | select avg(age(date_added)) FROM parts;
backend_type | background worker
-[ RECORD 2 ]----+----------------------------------------
pid | 21187
usename | achix
application_name | psql
client_addr |
backend_start | 2018-03-02 18:02:06.834787+02
xact_start | 2018-03-02 18:04:35.826065+02
query_start | 2018-03-02 18:04:35.826065+02
state | active
backend_xid |
backend_xmin | 438132638
query | select avg(age(date_added)) FROM parts;
backend_type | client backend
-[ RECORD 3 ]----+----------------------------------------
pid | 21306
usename | achix
application_name | psql
client_addr |
backend_start | 2018-03-02 18:04:35.837829+02
xact_start | 2018-03-02 18:04:35.836707+02
query_start | 2018-03-02 18:04:35.836707+02
state | active
backend_xid |
backend_xmin | 438132638
query | select avg(age(date_added)) FROM parts;
backend_type | background workerWidok pg_stat_activity dostarcza nam informacji o procesie backendu, użytkowniku, kliencie, transakcji, zapytaniu, stanie, a także wyczerpujące informacje o stanie oczekiwania na zapytanie.
Ale dlaczego 3 rzędy? W wersjach>=9.6, jeśli zapytanie może być uruchamiane równolegle lub jego części mogą być uruchamiane równolegle, a optymalizator uważa, że wykonywanie równoległe jest najszybszą strategią, wówczas tworzy Gather lub Zbierz scalanie węzła, a następnie żąda co najwyżej max_parallel_workers_per_gather procesy robocze w tle, których domyślnie jest 2, stąd 3 wiersze, które widzimy w powyższym wyjściu. Możemy odróżnić proces backendu klienta od pracownika działającego w tle, używając backend_type kolumna. Aby widok pg_stat_activity był włączony, musisz upewnić się, że parametr konfiguracji systemu track_activities jest włączony. Parametr pg_stat_activity zapewnia bogate informacje w celu określenia zablokowanych zapytań za pomocą kolumn wait_event_type i wait_event.
Bardziej wyrafinowanym sposobem monitorowania oświadczeń jest użycie pg_stat_statements rozszerzenie contribut, wspomniane wcześniej. W najnowszym systemie Linux (Ubuntu 17.10, PostgreSQL 9.6) można to dość łatwo zainstalować:
testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.
testdb=# \d pg_stat_statementsStwórzmy tabelę z 100000 wierszami, a następnie zresetujmy instrukcje pg_stat_statements, zrestartujmy serwer PostgreSQL, dokonaj wyboru na tej tabeli w (wciąż zimnym) systemie, a następnie zobaczmy zawartość instrukcji pg_stat_statements dla zaznaczenia:
testdb=# select 'descr '||gs as descr,gs as id into medtable from generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
shared_blks_hit | shared_blks_read
-----------------+------------------
0 | 541
(1 row)
testdb=#Teraz wykonajmy jeszcze raz zaznaczenie *, a następnie ponownie zajrzyjmy do zawartości pg_stat_statements dla tego zapytania:
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
shared_blks_hit | shared_blks_read
-----------------+------------------
541 | 541
(1 row)Tak więc za drugim razem instrukcja select znajdzie wszystkie wymagane bloki we współdzielonych buforach PostgreSQL, a pg_stat_statements zgłasza to przez shared_blks_hit . pg_stat_statements dostarcza informacji o całkowitej liczbie wywołań instrukcji, total_time, min_time, max_time i mean_time, co może być niezwykle pomocne przy próbie analizy obciążenia systemu. Powolne zapytanie, które jest uruchamiane bardzo często, powinno wymagać natychmiastowej uwagi. Podobnie, stale niskie współczynniki trafień mogą oznaczać konieczność przejrzenia shared_buffers ustawienie.
pg_stat_replication dostarcza informacji o aktualnym stanie replikacji dla każdego wal_sender. Załóżmy, że ustawiliśmy prostą topologię replikacji z naszym podstawowym i jednym gorącym trybem gotowości, a następnie możemy wysłać zapytanie o pg_stat_replication na podstawowym (wykonanie tego samego w trybie gotowości nie przyniesie żadnych wyników, chyba że mamy skonfigurowaną replikację kaskadową, a ten konkretny tryb gotowości służy jako upstream do innych rezerwowych urządzeń końcowych), aby zobaczyć aktualny stan replikacji:
testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 1317
usesysid | 10
usename | postgres
application_name | walreceiver
client_addr | 10.0.2.2
client_hostname |
client_port | 48192
backend_start | 2018-03-03 11:59:21.315524+00
backend_xmin |
state | streaming
sent_lsn | 0/3029DB8
write_lsn | 0/3029DB8
flush_lsn | 0/3029DB8
replay_lsn | 0/3029DB8
write_lag |
flush_lag |
replay_lag |
sync_priority | 0
sync_state | asyncCztery kolumny sent_lsn , write_lsn , flush_lsn , replay_lsn powiedz nam dokładną pozycję WAL na każdym etapie procesu replikacji w zdalnym trybie gotowości. Następnie tworzymy duży ruch na podstawowym za pomocą polecenia takiego jak:
testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;I spójrz ponownie na pg_stat_replication:
postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 1317
usesysid | 10
usename | postgres
application_name | walreceiver
client_addr | 10.0.2.2
client_hostname |
client_port | 48192
backend_start | 2018-03-03 11:59:21.315524+00
backend_xmin |
state | streaming
sent_lsn | 0/D5E0000
write_lsn | 0/D560000
flush_lsn | 0/D4E0000
replay_lsn | 0/C5FF0A0
write_lag | 00:00:04.166639
flush_lag | 00:00:04.180333
replay_lag | 00:00:04.614416
sync_priority | 0
sync_state | asyncTeraz widzimy, że mamy opóźnienie między głównym i rezerwowym, przedstawionym w sent_lsn , write_lsn , flush_lsn , replay_lsn wartości. Od PgSQL 10.0 pg_stat_replication pokazuje również opóźnienie między ostatnio opróżnionym lokalnie WAL a czasem potrzebnym na zdalne zapisanie, opróżnienie i odtworzenie. Widząc wartości null w tych 3 kolumnach, oznacza to, że główny i rezerwowy są zsynchronizowane.
Odpowiednik pg_stat_replication po stronie gotowości nazywa się:pg_stat_wal_receiver:
testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid | 17867
status | streaming
receive_start_lsn | 0/F000000
receive_start_tli | 1
received_lsn | 0/3163F210
received_tli | 1
last_msg_send_time | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn | 0/3163F210
latest_end_time | 2018-03-03 13:32:42.516551+00
slot_name | fbsdclone
conninfo | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any
testdb=#Gdy nie ma żadnej aktywności, a tryb gotowości odtworzył wszystko, to latest_end_lsn musi być równy sent_lsn na podstawowym (i wszystkich pośrednich numerach sekwencyjnych dziennika).
Podobnie jak w przypadku replikacji fizycznej, w przypadku replikacji logicznej, gdzie rolę podstawową przejmuje wydawca, a rezerwową subskrybent, naturalnie rolę pg_stat_wal_receiver jest pobierany przez pg_stat_subscription . Możemy zapytać pg_stat_subscription w następujący sposób:
testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid | 24615
subname | alltables_sub
pid | 1132
relid |
received_lsn | 0/33005498
last_msg_send_time | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn | 0/33005498
latest_end_time | 2018-03-03 17:05:36.004545+00Zwróć uwagę, że po stronie wydawcy odpowiedni widok jest taki sam jak w przypadku replikacji fizycznej:pg_stat_replication .
Wyświetlenia zebranych statystyk
pg_stat_archiver widok ma jeden wiersz, który zawiera informacje o archiwizatorze walu. Przechowywanie migawki tego wiersza w regularnych odstępach czasu pozwala obliczyć rozmiar ruchu WAL między tymi interwałami. Daje również informacje o błędach podczas archiwizacji plików WAL.
pg_stat_bgwriter widok zawiera bardzo ważne informacje na temat zachowania:
- Wskaźnik kontrolny
- Pisarz w tle
- Backendy (obsługa klienta)
Ponieważ ten widok podaje skumulowane dane od ostatniego resetowania, bardzo przydatne jest utworzenie kolejnej tabeli ze znacznikami czasu z okresowymi migawkami pg_stat_bgwriter , dzięki czemu łatwo będzie uzyskać przyrostową perspektywę między dwoma migawkami. Dostrajanie to nauka (lub magia) i wymaga obszernego rejestrowania i monitorowania, a także jasnego zrozumienia podstawowych pojęć i elementów wewnętrznych PostgreSQL, aby uzyskać dobre wyniki, a ten widok jest od czego zacząć, szukając takich rzeczy, jak:
- Czy punkty kontrolne_czasowe? zdecydowana większość wszystkich punktów kontrolnych? Jeśli nie, należy podjąć działania, zmierzyć wyniki i powtórzyć cały proces, aż nie zostaną znalezione żadne ulepszenia.
- Czy punkt kontrolny_buforów? znaczna większość nad pozostałymi dwoma rodzajami (buffers_clean ale co najważniejsze buffers_backend ) ? Jeśli wartości buffers_backend są wysokie, to znowu pewne parametry konfiguracji muszą zostać zmienione, należy wykonać nowe pomiary i ponownie je ocenić.
Pg_stat_[użytkownik|sys|wszystkie]_tabele
Najbardziej podstawowym zastosowaniem tych widoków jest sprawdzenie, czy nasza strategia próżniowa działa zgodnie z oczekiwaniami. Duże wartości martwych krotek w stosunku do żywych krotek oznaczają nieefektywne odkurzanie. Widoki te dostarczają również informacji na temat skanowania i pobierania sekwencji i indeksu, informacji o liczbie wierszy wstawionych, zaktualizowanych, usuniętych oraz aktualizacji HOT. Powinieneś starać się utrzymywać jak największą liczbę aktualizacji HOT, aby poprawić wydajność.
Pg_stat_[użytkownik|sys|wszystkie]_indexes
Tutaj system przechowuje i wyświetla informacje o indywidualnym wykorzystaniu indeksu. Należy pamiętać, że idx_tup_read jest dokładniejszy niż idx_tup_fetch. Nie PK/nieunikalne indeksy z niskim idx_scan należy rozważyć ich usunięcie, ponieważ utrudniają one tylko aktualizacje HOT. Jak wspomniano na poprzednim blogu, należy unikać nadmiernego indeksowania, indeksowanie wiąże się z kosztami.
Pg_statio_[użytkownik|sys|wszystkie]_tabele
W tych widokach możemy znaleźć informacje o wydajności pamięci podręcznej w odniesieniu do odczytów sterty tabeli, odczytów indeksów i odczytów TOAST. Proste zapytanie w celu zliczenia procentu trafień i rozkładu trafień w tabelach wyglądałoby następująco:
with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
relid | row_number | heap block hits % | In top %
-----------+------------+-------------------+-------------------
16599 | 1 | 99.9993058404502 | 0.373134328358209
18353 | 2 | 99.9992251425738 | 0.746268656716418
18338 | 3 | 99.99917566565 | 1.11940298507463
17269 | 4 | 99.9990617323798 | 1.49253731343284
18062 | 5 | 99.9988021889522 | 1.86567164179104
18075 | 6 | 99.9985334109273 | 2.23880597014925
18365 | 7 | 99.9968070500335 | 2.61194029850746
………..
18904 | 127 | 97.2972972972973 | 47.3880597014925
18801 | 128 | 97.1631205673759 | 47.7611940298507
16851 | 129 | 97.1428571428571 | 48.134328358209
17321 | 130 | 97.0043198249512 | 48.5074626865672
17136 | 131 | 97 | 48.8805970149254
17719 | 132 | 96.9791612263018 | 49.2537313432836
17688 | 133 | 96.969696969697 | 49.6268656716418
18872 | 134 | 96.9333333333333 | 50
17312 | 135 | 96.8181818181818 | 50.3731343283582
……………..
17829 | 220 | 60.2721026527734 | 82.089552238806
17332 | 221 | 60.0276625172891 | 82.4626865671642
18493 | 222 | 60 | 82.8358208955224
17757 | 223 | 59.7222222222222 | 83.2089552238806
17586 | 224 | 59.4827586206897 | 83.5820895522388To mówi nam, że co najmniej 50% stołów ma współczynnik trafień większy niż 96,93%, a 83,5% stołów ma współczynnik trafień lepszy niż 59,4%
Pg_statio_[użytkownik|sys|wszystkie]_indeksy
Ten widok zawiera informacje o blokowaniu/odczycie dla indeksów.
Pg_stat_database
Ten widok zawiera jeden wiersz na bazę danych. Pokazuje niektóre informacje z poprzednich widoków zagregowane do całej bazy danych (odczytane bloki, trafienia bloków, informacje o tups), niektóre informacje dotyczące całej bazy danych (łączna liczba xactions, pliki tymczasowe, konflikty, martwe zegary, czas odczytu/zapisu) , a na koniec liczba aktualnych backendów.
Rzeczy, na które należy zwrócić uwagę, to stosunek blks_hit/(blks_hit + blks_read) :im wyższa wartość, tym lepiej dla I/O systemu. Jednak chybienia niekoniecznie powinny być uwzględniane w odczytach dysku, ponieważ mogły one być bardzo dobrze obsługiwane przez pamięć podręczną plików systemu operacyjnego.
Podobnie jak w przypadku innych widoków zebranych statystyk wymienionych powyżej, należy utworzyć wersję pg_stat_database ze znacznikiem czasu zobacz i zobacz różnice między dwoma kolejnymi migawkami:
- Czy liczba wycofań rośnie?
- Czy liczba popełnionych działań?
- Czy mamy o wiele więcej konfliktów niż wczoraj (dotyczy to czuwania)?
- Czy mamy nienormalnie dużą liczbę zakleszczeń?
To wszystko są bardzo ważne dane. Pierwsze dwa mogą oznaczać pewną zmianę w pewnym wzorcu użytkowania, co należy wyjaśnić. Duża liczba konfliktów może oznaczać, że replikacja wymaga dostrojenia. Duża liczba zakleszczeń jest zła z wielu powodów. Nie tylko wydajność jest niska, ponieważ transakcje są wycofywane, ale także jeśli aplikacja cierpi z powodu zakleszczeń w topologii jednego mastera, problemy będą się nasilać tylko wtedy, gdy przejdziemy na multi-master. W takim przypadku dział inżynierii oprogramowania musi przepisać fragmenty kodu, które powodują zakleszczenia.
Zamki
Powiązane zasoby ClusterControl dla PostgreSQL Jak zarządzać istniejącym serwerem Postgres i monitorować go Jak porównywać wydajność PostgreSQLBlokowanie jest bardzo ważnym tematem w PostgreSQL i zasługuje na swój własny(e) blog(i). Niemniej jednak podstawowe monitorowanie śluz musi odbywać się w taki sam sposób, jak inne aspekty monitorowania przedstawione powyżej. pg_locks view dostarcza w czasie rzeczywistym informacji o aktualnych blokadach w systemie. Możemy złapać długo czekające blokady, ustawiając log_lock_waits , wówczas informacja o długim oczekiwaniu zostanie zapisana w logu PgSQL. Jeśli zauważymy nietypowo wysokie blokowanie, które skutkuje długimi oczekiwaniem, to znowu, jak w przypadku wspomnianych powyżej zakleszczeń, inżynierowie oprogramowania muszą przejrzeć wszelkie fragmenty kodu, które mogą powodować długo utrzymywane blokady, np. jawne blokowanie w aplikacji (LOCK TABLE lub SELECT … FOR UPDATE).
Podobnie jak w przypadku impasów, system z krótkimi blokadami łatwiej przejdzie do konfiguracji z wieloma wzorcami.
