Sdílet prostřednictvím

Řešení potíží s vysokým využitím procesoru na flexibilním serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

V tomto článku se dozvíte, jak rychle identifikovat hlavní příčinu vysokého využití procesoru a možné nápravné akce pro řízení využití procesoru při použití flexibilního serveru Azure Database for PostgreSQL.

V tomto článku se dozvíte:

  • 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
  • Informace o nástrojích pro identifikaci vysokého využití procesoru, jako jsou metriky Azure, úložiště dotazů a pg_stat_statements
  • Jak identifikovat původní příčiny, jako jsou dlouhotrvající dotazy a celková připojení.
  • Řešení vysokého využití procesoru pomocí tabulek Vysvětlit analýzu, sdružování připojení a Vakuové tabulky

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ěpodobné hlavní příčiny a doporučení pro zmírnění vysokého využití procesoru. 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í procesoru

Zvažte tyto nástroje k identifikaci vysokého využití procesoru.

Metriky Azure

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

Úložiště dotazů

Úložiště dotazů automaticky zaznamenává historii dotazů a statistik modulu runtime a uchovává je pro vaši kontrolu. Data se rozkryjí podle času, abyste viděli 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 Úložiště dotazů.

pg_stat_statements

Rozšíření pg_stat_statements pomáhá identifikovat dotazy, které spotřebovávají čas na serveru.

Střední nebo průměrná doba provádění

Pro Postgres verze 13 a vyšší použijte následující příkaz k zobrazení prvních pěti příkazů SQL průměrem nebo průměrnou dobou provádění:

SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;

Celková doba provádění

Spuštěním následujících příkazů zobrazte prvních pět příkazů SQL podle celkové doby provádění.

Pro Postgres verze 13 a vyšší použijte následující příkaz k zobrazení prvních pěti příkazů SQL podle celkové doby provádění:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;

Identifikace původních příčin

Pokud jsou úrovně spotřeby procesoru obecně vysoké, může to být možné hlavní příčiny:

Dlouhotrvající transakce

Dlouhotrvající transakce můžou využívat prostředky procesoru, které můžou vést k vysokému využití procesoru.

Následující dotaz pomáhá identifikovat připojení spuštěná po nejdelší dobu:

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;

Celkový počet připojení a počet připojení podle stavu

Dalším problémem, který může vést ke zvýšení využití procesoru a paměti, je velký počet připojení k databázi.

Následující dotaz poskytuje informace o počtu připojení podle stavu:

SELECT state, count(*)
FROM  pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;

Řešení vysokého využití procesoru

K vyřešení vysokého využití procesoru použijte funkci Explain Analyze, PG Bouncer, sdružování připojení a ukončování dlouhotrvajících transakcí.

Použití funkce Vysvětlit analýzu

Jakmile znáte dotaz, který běží dlouhou dobu, použijte funkci EXPLAIN k dalšímu prozkoumání dotazu a jeho ladění.
Další informace o příkazu EXPLAIN najdete v tématu Vysvětlit plán.

PGBouncer a sdružování připojení

V situacích, kdy existuje velké množství nečinných připojení nebo velké množství připojení, které využívají procesor, zvažte použití nástroje pro sdružování připojení, jako je PgBouncer.

Další podrobnosti o pgBouncer najdete v tématu:

Sdružování připojení

Osvědčené postupy

Flexibilní server Azure Database for PostgreSQL nabízí PgBouncer jako integrované řešení sdružování připojení. Další informace najdete v tématu PgBouncer

Ukončení dlouhotrvajících transakcí

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

Pokud chcete ukončit identifikátor PID relace, budete muset identifikovat 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í, jako usename je (uživatelské jméno), datname (název databáze) atd.

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

SELECT pg_terminate_backend(pid);

Monitorování statistik vakua a tabulek

Udržování statistik tabulek v aktualizovaném stavu pomáhá zlepšit výkon dotazů. Monitorujte, jestli se provádí pravidelné automatické úklidy.

Následující dotaz pomáhá identifikovat tabulky, které potřebují úklid:

select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;

last_autovacuum sloupce last_autoanalyze poskytují datum a čas posledního automatického úklidu nebo analýzy tabulky. Pokud se tabulky pravidelně nevysávají, proveďte kroky k ladění automatického úklidu. Další informace o řešení potíží s automatickým úklidem a ladění najdete v tématu Řešení potíží s automatickým úklidem.

Krátkodobé řešení by mělo provést ruční vakuovou analýzu tabulek, ve kterých se zobrazují pomalé dotazy:

vacuum analyze <table_name>;

Související obsah