Dela via

Felsöka hög CPU-användning i Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

I den här artikeln beskrivs hur du identifierar rotorsaken till hög CPU-användning. Det ger också möjliga åtgärder för att kontrollera CPU-användningen när du använder Azure Database for PostgreSQL – flexibel server.

I den här artikeln kan du lära dig:

  • Om felsökningsguider för att identifiera och få rekommendationer för att minimera rotorsaker.
  • Om verktyg för att identifiera hög CPU-användning, till exempel Azure Metrics, frågearkiv och pg_stat_statements.
  • Så här identifierar du rotorsaker, till exempel tidskrävande frågor och totala anslutningar.
  • Så här löser du hög CPU-användning med hjälp av EXPLAIN ANALYZE, anslutningspooler och dammsugningstabeller.

Felsökningsguider

Med hjälp av felsökningsguiderna kan du identifiera den troliga rotorsaken till ett scenario med hög CPU-användning och läsa igenom rekommendationer för att åtgärda problemet.

Om du vill lära dig hur du konfigurerar och använder felsökningsguiderna följer du felsökningsguiderna för installation.

Verktyg för att identifiera hög CPU-användning

Överväg att använda följande lista över verktyg för att identifiera hög CPU-användning.

Azure-mått

Azure Metrics är en bra utgångspunkt för att kontrollera processoranvändningen under en viss period. Mått ger information om de resurser som används under den period då processoranvändningen är hög. Jämför graferna för skriv-IOP:er, läs-IOP:er, Byte/sek för läsdataflöde och Byte/sek för skrivning av dataflöde med CPU-procent för att ta reda på tidpunkter när arbetsbelastningen orsakade hög CPU.

För proaktiv övervakning kan du konfigurera aviseringar för måtten. Stegvis vägledning finns i Azure Metrics.

Query Store

Frågearkivet samlar automatiskt in historiken för frågor och körningsstatistik och behåller dem för din granskning. Den delar upp data efter tid så att du kan se tidsmässiga användningsmönster. Data för alla användare, databaser och frågor lagras i en databas med namnet azure_sys i azure database for PostgreSQL– flexibel serverinstans.

Frågearkivet kan korrelera information om väntehändelser med frågekörningstidsstatistik. Använd frågearkivet för att identifiera frågor som har hög CPU-förbrukning under den aktuella perioden.

Mer information finns i frågearkivet.

pg_stat_statements

Tillägget pg_stat_statements hjälper till att identifiera frågor som förbrukar tid på servern. Mer information om det här tillägget finns i dokumentationen.

Genomsnittlig eller genomsnittlig körningstid

För Postgres version 13 och senare använder du följande instruktion för att visa de fem främsta SQL-uttrycken efter genomsnittlig eller genomsnittlig körningstid:

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

Total körningstid

Kör följande instruktioner för att visa de fem främsta SQL-uttrycken efter total körningstid.

För Postgres version 13 och senare använder du följande instruktion för att visa de fem främsta SQL-uttrycken efter total körningstid:

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

Identifiera rotorsaker

Om cpu-förbrukningsnivåerna är höga i allmänhet kan följande vara möjliga grundorsaker:

Långvariga transaktioner

Långvariga transaktioner kan förbruka CPU-resurser som kan leda till hög CPU-användning.

Följande fråga hjälper dig att identifiera anslutningar som körs under den längsta tiden:

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;

Totalt antal anslutningar och antal anslutningar per tillstånd

Ett stort antal anslutningar till databasen kan också leda till ökad processor- och minnesanvändning.

Följande fråga ger information om antalet anslutningar efter tillstånd:

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

Lösa hög CPU-användning

Använd EXPLAIN ANALYZE, överväg att använda den inbyggda PgBouncer-anslutningspoolen och avsluta långvariga transaktioner för att lösa hög CPU-användning.

Använda EXPLAIN ANALYZE

När du känner till de frågor som förbrukar mer CPU använder du EXPLAIN ANALYZE för att undersöka och finjustera dem ytterligare.

Mer information om kommandot EXPLAIN ANALYZE finns i dokumentationen.

PgBouncer, en inbyggd anslutningspool

I situationer där det finns många kortvariga anslutningar, eller många anslutningar som förblir inaktiva under större delen av sitt liv, bör du överväga att använda en anslutningspool som PgBouncer.

Mer information om PgBouncer finns i metodtips för anslutningspooler och anslutningshantering med PostgreSQL

Azure Database for PostgreSQL – flexibel server erbjuder PgBouncer som en inbyggd lösning för anslutningspooler. Mer information finns i PgBouncer.

Avsluta långvariga transaktioner

Du kan överväga att döda en tidskrävande transaktion som ett alternativ.

Om du vill avsluta en sessions PID måste du hitta dess PID med hjälp av följande fråga:

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;

Du kan också filtrera efter andra egenskaper som usename (användarnamn), datname (databasnamn) osv.

När du har sessionens PID kan du avsluta den med hjälp av följande fråga:

SELECT pg_terminate_backend(pid);

Övervaka vakuum- och tabellstatistik

Genom att hålla tabellstatistiken uppdaterad kan du förbättra frågeprestandan. Övervaka om regelbunden autovacuuming utförs.

Följande fråga hjälper till att identifiera de tabeller som behöver dammsugas:

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 och last_autoanalyze kolumner ger datum och tid när tabellen senast autovacuumed eller analyserades. Om tabellerna inte dammsugs regelbundet vidtar du åtgärder för att justera autovacuum.

Mer information om felsökning och justering av autovacuum finns i Autovacuum-felsökning.

En kortsiktig lösning skulle vara att göra en manuell vakuumanalys av tabellerna där långsamma frågor visas:

VACUUM ANALYZE <table>;

Dela dina förslag och buggar med produktteamet för Azure Database for PostgreSQL.