Udostępnij za pośrednictwem

Rozwiązywanie problemów z wysokim użyciem operacji we/wy na sekundę dla usługi Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W tym artykule pokazano, jak szybko zidentyfikować główną przyczynę wysokiego wykorzystania operacji we/wy na sekundę (operacji wejścia/wyjścia) i przedstawiono akcje naprawcze w celu kontrolowania wykorzystania operacji we/wy na sekundę podczas korzystania z elastycznego serwera usługi Azure Database for PostgreSQL.

W tym artykule omówiono sposób wykonywania następujących zadań:

  • Informacje o przewodnikach rozwiązywania problemów w celu identyfikowania i uzyskiwania zaleceń w celu ograniczenia głównych przyczyn.
  • Użyj narzędzi do identyfikowania wysokiego wykorzystania operacji wejścia/wyjścia (we/wy), takich jak metryki platformy Azure, magazyn zapytań i pg_stat_statements.
  • Zidentyfikuj główne przyczyny, takie jak długotrwałe zapytania, chronometraż punktów kontrolnych, destrukcyjny proces automatycznego czyszczenia demona i wysokie wykorzystanie magazynu.
  • Rozwiąż wysokie wykorzystanie operacji we/wy przy użyciu funkcji Wyjaśnij analizę, dostrajaj parametry serwera związane z punktem kontrolnym i dostrajaj demona automatycznego czyszczenia.

Przewodniki rozwiązywania problemów

Korzystając z przewodników rozwiązywania problemów z funkcją, które są dostępne w portalu serwera elastycznego usługi Azure Database for PostgreSQL, można znaleźć prawdopodobną główną przyczynę i zalecenia dotyczące ograniczenia wysokiego użycia operacji we/wy na sekundę. Jak skonfigurować przewodniki rozwiązywania problemów, aby ich używać, postępuj zgodnie z przewodnikami rozwiązywania problemów z konfiguracją.

Narzędzia do identyfikowania wysokiego wykorzystania operacji we/wy

Rozważ następujące narzędzia, aby zidentyfikować wysokie wykorzystanie operacji we/wy.

Metryki platformy Azure

Metryki platformy Azure to dobry punkt wyjścia do sprawdzenia wykorzystania operacji we/wy dla zdefiniowanej daty i okresu. Metryki zawierają informacje o czasie, w którym wykorzystanie operacji we/wy jest wysokie. Porównaj wykresy operacji we/wy zapisu, operacji we/wy odczytu, przepływności odczytu i przepływności zapisu, aby dowiedzieć się, kiedy obciążenie powoduje wysokie wykorzystanie operacji we/wy. W celu proaktywnego monitorowania można skonfigurować alerty dotyczące metryk. Aby uzyskać szczegółowe wskazówki, zobacz Azure Metrics (Metryki platformy Azure).

Magazyn zapytań

Funkcja Magazynu zapytań automatycznie przechwytuje historię zapytań i statystyk środowiska uruchomieniowego i zachowuje je do przeglądu. Wycinekuje dane według czasu, aby zobaczyć wzorce użycia czasowego. Dane dla wszystkich użytkowników, baz danych i zapytań są przechowywane w bazie danych o nazwie azure_sys w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL. Aby uzyskać szczegółowe wskazówki, zobacz Monitorowanie wydajności za pomocą magazynu zapytań.

Użyj następującej instrukcji, aby wyświetlić pięć pierwszych instrukcji SQL korzystających z operacji we/wy:

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

Rozszerzenie pg_stat_statements

Rozszerzenie pg_stat_statements ułatwia identyfikowanie zapytań korzystających z operacji we/wy na serwerze.

Użyj następującej instrukcji, aby wyświetlić pięć pierwszych instrukcji SQL korzystających z operacji we/wy:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

Uwaga

W przypadku używania magazynu zapytań lub pg_stat_statements dla kolumn blk_read_time i blk_write_time do wypełnienia należy włączyć parametr track_io_timingserwera . Aby uzyskać więcej informacji na temat programu , zapoznaj się z track_io_timingtematem Parametry serwera.

Identyfikowanie głównych przyczyn

Jeśli ogólne poziomy użycia we/wy są wysokie, mogą to być główne przyczyny:

Długotrwałe transakcje

Długotrwałe transakcje mogą zużywać operacje we/wy, co może prowadzić do wysokiego wykorzystania operacji we/wy.

Następujące zapytanie pomaga zidentyfikować połączenia, które są uruchomione przez najdłuższy czas:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Chronometraż punktu kontrolnego

Wysokie we/wy można również zobaczyć w scenariuszach, w których punkt kontrolny występuje zbyt często. Jednym ze sposobów identyfikacji jest sprawdzenie pliku dziennika serwera elastycznego usługi Azure Database for PostgreSQL pod kątem następującego tekstu dziennika: "DZIENNIK: punkty kontrolne występują zbyt często".

Można również zbadać przy użyciu podejścia, w którym są zapisywane okresowe migawki pg_stat_bgwriter z sygnaturą czasową. Korzystając z zapisanych migawek, można obliczyć średni interwał punktu kontrolnego, liczbę żądanych punktów kontrolnych i liczbę punktów kontrolnych z upływem czasu.

Destrukcyjny proces demona automatycznego czyszczenia

Uruchom następujące zapytanie, aby monitorować automatyczne czyszczenie:

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

Zapytanie służy do sprawdzania, jak często tabele w bazie danych są opróżniane.

  • last_autovacuum: data i godzina ostatniego uruchomienia automatycznego czyszczenia w tabeli.
  • autovacuum_count: liczba opróżnień tabeli.
  • autoanalyze_count: liczba analiz tabeli.

Rozwiązywanie problemów z wysokim wykorzystaniem operacji We/Wy

Aby rozwiązać problemy z wysokim wykorzystaniem operacji we/wy, możesz użyć dowolnej z następujących trzech metod.

Polecenie EXPLAIN ANALYZE

Po zidentyfikowaniu zapytania, które zużywa wysokie we/wy, użyj polecenia EXPLAIN ANALYZE , aby dokładniej zbadać zapytanie i go dostroić. Aby uzyskać więcej informacji na temat EXPLAIN ANALYZE polecenia, zapoznaj się z planem WYJAŚNIJ.

Kończenie długotrwałych transakcji

Możesz rozważyć zabicie długotrwałej transakcji jako opcji.

Aby zakończyć identyfikator procesu sesji (PID), należy wykryć identyfikator PID przy użyciu następującego zapytania:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Możesz również filtrować według innych właściwości, takich jak usename (nazwa użytkownika) lub datname (nazwa bazy danych).

Po wprowadzeniu identyfikatora PID sesji można ją zakończyć, używając następującego zapytania:

SELECT pg_terminate_backend(pid);

Dostrajanie parametrów serwera

Jeśli zauważysz, że punkt kontrolny występuje zbyt często, zwiększ max_wal_size parametr serwera do momentu, aż większość punktów kontrolnych będzie sterowana czasem, zamiast żądać. Ostatecznie 90 procent lub więcej powinno być oparte na czasie, a interwał między dwoma punktami kontrolnymi powinien być zbliżony do checkpoint_timeout wartości ustawionej na serwerze.

  • max_wal_size: Szczytowe godziny pracy to dobry moment na dotarcie max_wal_size do wartości. Aby uzyskać wartość, wykonaj następujące czynności:

    1. Uruchom następujące zapytanie, aby uzyskać bieżącą nazwę LSN WAL, a następnie zanotuj wynik:

      select pg_current_wal_lsn();

    2. Poczekaj kilka checkpoint_timeout sekund. Uruchom następujące zapytanie, aby uzyskać bieżącą nazwę LSN WAL, a następnie zanotuj wynik:

      select pg_current_wal_lsn();

    3. Uruchom następujące zapytanie, które używa dwóch wyników, aby sprawdzić różnicę w gigabajtach (GB):

      select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;

  • checkpoint_completion_target: Dobrym rozwiązaniem jest ustawienie wartości 0,9. Na przykład wartość 0,9 dla checkpoint_timeout 5 minut wskazuje, że celem ukończenia punktu kontrolnego jest 270 sekund (0,9*300 sekund). Wartość 0,9 zapewnia dość spójne obciążenie we/wy. Agresywna wartość checkpoint_completion_target może spowodować zwiększenie obciążenia we/wy na serwerze.

  • checkpoint_timeout: Możesz zwiększyć checkpoint_timeout wartość z wartości domyślnej ustawionej na serwerze. Podczas zwiększania wartości należy wziąć pod uwagę, że zwiększenie go również zwiększy czas odzyskiwania awaryjnego.

Dostrajanie automatycznego czyszczenia w celu zmniejszenia zakłóceń

Aby uzyskać więcej informacji na temat monitorowania i dostrajania w scenariuszach, w których automatyczne czyszczenie jest zbyt destrukcyjne, zobacz Dostrajanie automatycznego czyszczenia.

Zwiększanie magazynu

Zwiększenie magazynu pomaga w przypadku dodawania większej liczby operacji we/wy na sekundę na serwer. Aby uzyskać więcej informacji na temat magazynu i skojarzonej liczby operacji we/wy na sekundę, zobacz Opcje obliczeń i magazynu.

Powiązana zawartość