Rozwiązywanie problemów z wysokim wykorzystaniem IOPS w usłudze 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 zapewnia działania naprawcze w celu kontrolowania wykorzystania operacji we/wy na sekundę podczas korzystania z usługi Azure Database for PostgreSQL.

W tym artykule dowiesz się, jak:

  • Informacje o przewodnikach rozwiązywania problemów w celu identyfikowania i uzyskiwania zaleceń w celu ograniczenia głównych przyczyn.
  • Użyj narzędzi do określania wysokiego wykorzystania operacji we/wy, takich jak Azure Metrics, Query Store i pg_stat_statements.
  • Zidentyfikuj główne przyczyny, takie jak długotrwałe zapytania, czasy występowania punktów kontrolnych, zakłócający proces demona autovacuum oraz wysokie wykorzystanie pamięci masowej.
  • Rozwiąż wysokie wykorzystanie we/wy przy użyciu funkcji Wyjaśnij analizę, dostrajaj parametry związane z punktem kontrolnym i dostrajaj demona automatycznego czyszczenia.

Przewodniki rozwiązywania problemów

Korzystając z przewodników rozwiązywania problemów dotyczących funkcji, które są dostępne w portalu Azure Database for PostgreSQL, można znaleźć prawdopodobną główną przyczynę i zalecenia dotyczące ograniczenia wysokiego wykorzystania operacji we/wy (IOPS). Aby skonfigurować przewodniki rozwiązywania problemów do użycia, postępuj zgodnie z instrukcją konfiguracji przewodników rozwiązywania problemów.

Narzędzia do identyfikacji wysokiego wykorzystania zasobów we/wy

Skorzystaj z następujących narzędzi, aby zidentyfikować wysokie wykorzystanie wejścia/wyjścia (I/O).

Metryki Azure

Metryki platformy Azure to dobry punkt wyjścia do sprawdzenia wykorzystania operacji we/wy dla zdefiniowanej daty i okresu. Metryki dostarczają informacji o okresie, w którym wykorzystanie wejścia/wyjścia (I/O) 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. Dzieli dane w podziale na czas, aby zobaczyć wzorce użycia w czasie. 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ć instrukcje krok po kroku, zobacz Monitorowanie wydajności za pomocą funkcji Query Store.

Użyj następującej instrukcji, aby wyświetlić pięć instrukcji SQL zużywających najwięcej 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ęć instrukcji SQL zużywających najwięcej operacji we/wy:

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

Uwaga / Notatka

Aby podczas korzystania z magazynu zapytań lub pg_stat_statements kolumny blk_read_time i blk_write_time były wypełniane, należy włączyć parametr track_io_timing. Aby uzyskać więcej informacji na temat track_io_timing, zobacz Parametry.

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ą obciążać operacje we/wy, co może prowadzić do ich wysokiego wykorzystania.

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;

Czasy punktu kontrolnego

Wysokie I/O może również występować w sytuacjach, gdy punkt kontrolny jest wykonywany zbyt często. Jednym ze sposobów identyfikacji jest sprawdzenie pliku dziennika wystąpienia 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ż przeprowadzić analizę, stosując podejście polegające na zapisywaniu okresowych migawek pg_stat_bgwriter ze znacznikiem czasu. 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ć autovacuum:

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ąż problem wysokiego wykorzystania we/wy

Aby zaradzić wysokiemu wykorzystaniu wejścia/wyjścia (I/O), możesz skorzystać z jednej z poniższych 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 o poleceniu EXPLAIN ANALYZE, zapoznaj się z planem EXPLAIN.

Kończenie długotrwałych transakcji

Możesz rozważyć zakończenie długotrwałej transakcji jako opcję.

Aby zakończyć proces sesji o danym identyfikatorze PID, należy najpierw ustalić ten PID za pomocą 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);

Dostosuj parametry

Jeśli zauważysz, że punkty kontrolne występują zbyt często, zwiększ wartość parametru max_wal_size, aż większość punktów kontrolnych będzie inicjowana przez upływ czasu, a nie na żądanie. 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: Godziny szczytu to dobry moment na ustalenie wartości max_wal_size. Aby uzyskać wartość, wykonaj następujące czynności:

    1. Uruchom następujące zapytanie, aby uzyskać bieżący numer 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żący numer 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. Zwiększając wartość, należy wziąć pod uwagę, że jej zwiększenie wydłuży również czas odzyskiwania po awarii.

Dostrój autovacuum, aby ograniczyć zakłócenia

Aby uzyskać więcej informacji na temat monitorowania i dostrajania w scenariuszach, w których autovacuum jest zbyt uciążliwy, zapoznaj się z Dostrajaniem autovacuum.

Zwiększanie magazynu

Zwiększenie przestrzeni dyskowej pomaga, gdy zwiększasz liczbę operacji IOPS na serwerze. Aby uzyskać więcej informacji o magazynowaniu i powiązanych wartościach IOPS, zapoznaj się z sekcją Opcje obliczeń i magazynowania.

Treści powiązane

  • Last updated on