Sdílet prostřednictvím


Řešení potíží s vysokým využitím IOPS pro flexibilní server Azure Database for PostgreSQL

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Tento článek ukazuje, jak rychle identifikovat hlavní příčinu vysokého využití vstupně-výstupních operací za sekundu (vstupně-výstupní operace) a poskytuje nápravné akce pro řízení využití IOPS při použití flexibilního serveru Azure Database for PostgreSQL.

V tomto článku získáte informace o těchto tématech:

  • O průvodcích odstraňováním potíží s identifikací a získáním doporučení ke zmírnění původních příčin
  • Pomocí nástrojů můžete identifikovat vysoké využití vstupu a výstupu (V/V), jako jsou metriky Azure, úložiště dotazů a pg_stat_statements.
  • Identifikujte původní příčiny, jako jsou dlouhotrvající dotazy, časování kontrolních bodů, rušivý proces démona automatického úklidu a vysoké využití úložiště.
  • Při řešení vysokého využití vstupně-výstupních operací využijte funkci Vysvětlit analýzu, vylaďte parametry serveru související s kontrolními body a vylaďte démona automatického úklidu.

Průvodce řešením potíží

S využitím průvodců odstraňováním potíží s funkcemi, které jsou k dispozici na portálu flexibilního serveru Azure Database for PostgreSQL, najdete pravděpodobnou hlavní příčinu a doporučení ke zmírnění scénáře vysokého využití IOPS. Postup nastavení průvodců odstraňováním potíží tak, aby je používal, postupujte podle průvodců odstraňováním potíží s nastavením.

Nástroje pro identifikaci vysokého využití vstupně-výstupních operací

Zvažte následující nástroje k identifikaci vysokého využití vstupně-výstupních operací.

Metriky Azure

Metriky Azure jsou dobrým výchozím bodem pro kontrolu využití vstupně-výstupních operací pro definované datum a období. Metriky poskytují informace o době, během které je vysoké využití vstupně-výstupních operací. Porovnejte grafy vstupně-výstupních operací zápisu, vstupně-výstupních operací čtení, propustnosti čtení a propustnosti zápisu a zjistěte, kdy úloha způsobuje vysoké využití vstupně-výstupních operací. Proaktivní monitorování můžete nakonfigurovat upozornění na metriky. Podrobné pokyny najdete v tématu Metriky Azure.

Úložiště dotazů

Funkce Úložiště dotazů automaticky zaznamenává historii dotazů a statistik modulu runtime a uchovává je pro vaši kontrolu. Data se rozsadí podle času, aby se zobrazily vzory dočasného použití. Data pro všechny uživatele, databáze a dotazy se ukládají do databáze s názvem azure_sys v instanci flexibilního serveru Azure Database for PostgreSQL. Podrobné pokyny najdete v tématu Monitorování výkonu úložiště dotazů.

Pomocí následujícího příkazu zobrazte prvních pět příkazů SQL, které spotřebovávají vstupně-výstupní operace:

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

Rozšíření pg_stat_statements

Toto pg_stat_statements rozšíření pomáhá identifikovat dotazy, které spotřebovávají vstupně-výstupní operace na serveru.

Pomocí následujícího příkazu zobrazte prvních pět příkazů SQL, které spotřebovávají vstupně-výstupní operace:

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

Poznámka:

Pokud používáte úložiště dotazů nebo pg_stat_statements pro sloupce, blk_read_time a blk_write_time, musíte povolit parametr track_io_timingserveru . Další informace o track_io_timingparametrech serveru najdete v tématu Parametry serveru.

Identifikace původních příčin

Pokud jsou úrovně spotřeby vstupně-výstupních operací obecně vysoké, může to být hlavní příčiny:

Dlouhotrvající transakce

Dlouhotrvající transakce můžou využívat vstupně-výstupní operace, což může vést k vysokému využití vstupně-výstupních operací.

Následující dotaz pomáhá identifikovat připojení, která běží nejdéle:

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;

Časování kontrolních bodů

Vysoké vstupně-výstupní operace se také dají vidět ve scénářích, kdy se kontrolní bod děje příliš často. Jedním ze způsobů, jak to identifikovat, je kontrola souboru protokolu flexibilního serveru Azure Database for PostgreSQL pro následující text protokolu: PROTOKOL: Kontrolní body se vyskytují příliš často.

Můžete také prozkoumat pomocí přístupu, kdy se ukládají pravidelné snímky pg_stat_bgwriter s časovým razítkem. Pomocí uložených snímků můžete vypočítat průměrný interval kontrolního bodu, počet požadovaných kontrolních bodů a počet časových časového limitu kontrolních bodů.

Proces démona rušivého automatického úklidu

Spuštěním následujícího dotazu monitorujte automatické úklidy:

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;

Dotaz slouží ke kontrole četnosti úklidu tabulek v databázi.

  • last_autovacuum: Datum a čas posledního automatického úklidu spuštěného v tabulce.
  • autovacuum_count: Počet vysávání tabulky.
  • autoanalyze_count: Kolikrát byla tabulka analyzována.

Řešení problémů s vysokým využitím VV operací

Pokud chcete vyřešit vysoké využití vstupně-výstupních operací, můžete použít některou z následujících tří metod.

Příkaz EXPLAIN ANALYZE

Jakmile identifikujete dotaz, který využívá vysoké vstupně-výstupní operace, použijte EXPLAIN ANALYZE k dalšímu prozkoumání dotazu a jeho ladění. Další informace o EXPLAIN ANALYZE příkazu najdete v plánu EXPLAIN.

Ukončení dlouhotrvajících transakcí

Můžete zvážit zabití dlouhotrvající transakce jako možnosti.

Pokud chcete ukončit ID procesu relace (PID), je potřeba zjistit PID pomocí následujícího dotazu:

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;

Můžete také filtrovat podle jiných vlastností, například usename (uživatelské jméno) nebo datname (název databáze).

Jakmile budete mít PID relace, můžete ho ukončit pomocí následujícího dotazu:

SELECT pg_terminate_backend(pid);

Ladění parametrů serveru

Pokud zjistíte, že k kontrolnímu bodu dochází příliš často, zvyšte max_wal_size parametr serveru, dokud se nezobrazuje časová kontrola většiny kontrolních bodů. Nakonec by mělo být založeno 90 procent nebo více času a interval mezi dvěma kontrolními body by měl být blízko checkpoint_timeout hodnotě nastavené na serveru.

  • max_wal_size: Špička v pracovní době je vhodná doba k tomu, aby přišla na max_wal_size hodnotu. Pokud chcete získat hodnotu, postupujte takto:

    1. Spuštěním následujícího dotazu získejte aktuální WAL LSN a poznamenejte si výsledek:

      select pg_current_wal_lsn();
      
    2. Počkejte několik checkpoint_timeout sekund. Spuštěním následujícího dotazu získejte aktuální WAL LSN a poznamenejte si výsledek:

      select pg_current_wal_lsn();
      
    3. Spuštěním následujícího dotazu, který používá dva výsledky, zkontrolujte rozdíl v gigabajtech (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: Osvědčeným postupem je nastavit hodnotu na hodnotu 0,9. Například hodnota 0,9 po checkpoint_timeout dobu 5 minut značí, že cíl k dokončení kontrolního bodu je 270 sekund (0,9*300 sekund). Hodnota 0,9 poskytuje poměrně konzistentní vstupně-výstupní zatížení. Agresivní hodnota může vést ke zvýšenému zatížení vstupně-výstupních checkpoint_completion_target operací na serveru.

  • checkpoint_timeout: Hodnotu můžete zvýšit checkpoint_timeout z výchozí hodnoty nastavené na serveru. Při zvyšování hodnoty vezměte v úvahu, že zvýšení by také zvýšilo dobu zotavení po havárii.

Ladění automatického úklidu za účelem snížení přerušení

Další informace o monitorování a ladění ve scénářích, kde je autovacuum příliš rušivé, najdete v tématu Ladění automatického úklidu.

Zvětšení úložiště

Zvýšení úložiště pomáhá při přidávání dalších vstupně-výstupních operací za sekundu na server. Další informace o úložišti a přidružených vstupně-výstupních operacích za sekundu najdete v možnostech výpočetních prostředků a úložiště.