Problemen met hoog CPU-gebruik in Azure Database for PostgreSQL - Flexible Server oplossen
VAN TOEPASSING OP:
Azure Database for PostgreSQL - Flexibele server
In dit artikel leest u hoe u snel de hoofdoorzaak van een hoog CPU-gebruik kunt identificeren en mogelijke herstelacties kunt uitvoeren om het CPU-gebruik te beheren bij het gebruik van flexibele Azure Database for PostgreSQL-server.
In dit artikel leert u het volgende:
- Informatie over probleemoplossingsgidsen voor het identificeren en verkrijgen van aanbevelingen om de hoofdoorzaken te beperken.
- Informatie over hulpprogramma's voor het identificeren van hoog CPU-gebruik, zoals metrische gegevens van Azure, Query Store en pg_stat_statements.
- Hoofdoorzaken identificeren, zoals langlopende query's en totale verbindingen.
- Een hoog CPU-gebruik oplossen met behulp van tabellen Explain Analyze, Verbinding maken ion Pooling en Vacuuming.
Handleidingen voor probleemoplossing
Met behulp van de handleidingen voor het oplossen van problemen met functies die beschikbaar zijn in de flexibele Server-portal van Azure Database for PostgreSQL, vindt u de mogelijke hoofdoorzaak en aanbevelingen voor het beperken van een hoog CPU-scenario. Volg de handleidingen voor probleemoplossing om deze te gebruiken. Volg de handleidingen voor het oplossen van problemen met setups.
Hulpprogramma's voor het identificeren van hoog CPU-gebruik
Overweeg deze hulpprogramma's om een hoog CPU-gebruik te identificeren.
Metrische gegevens van Azure
Metrische gegevens van Azure zijn een goed startpunt om het CPU-gebruik voor de bepaalde datum en periode te controleren. Metrische gegevens geven informatie over de tijdsduur waarin het CPU-gebruik hoog is. Vergelijk de grafieken van SCHRIJF-IOPS, LEES-IOPS, Leesdoorvoer en Schrijfdoorvoer met CPU-gebruik om te achterhalen wanneer de werkbelasting een hoge CPU heeft veroorzaakt. Voor proactieve bewaking kunt u waarschuwingen voor de metrische gegevens configureren. Zie Metrische gegevens van Azure voor stapsgewijze instructies.
Query Store
Query Store legt automatisch de geschiedenis van query's en runtimestatistieken vast en behoudt deze voor uw beoordeling. Hiermee worden de gegevens gesegmenteerd op tijd, zodat u tijdelijke gebruikspatronen kunt zien. Gegevens voor alle gebruikers, databases en query's worden opgeslagen in een database met de naam azure_sys in het flexibele serverexemplaren van Azure Database for PostgreSQL. Zie Query Store voor stapsgewijze instructies.
pg_stat_statements
De pg_stat_statements-extensie helpt bij het identificeren van query's die tijd verbruiken op de server.
Gemiddelde of gemiddelde uitvoeringstijd
Voor Postgres-versies 13 en hoger gebruikt u de volgende instructie om de vijf belangrijkste SQL-instructies te bekijken met gemiddelde of gemiddelde uitvoeringstijd:
SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;
Totale uitvoeringstijd
Voer de volgende instructies uit om de vijf belangrijkste SQL-instructies weer te geven op basis van de totale uitvoeringstijd.
Voor Postgres-versies 13 en hoger gebruikt u de volgende instructie om de vijf belangrijkste SQL-instructies weer te geven op basis van de totale uitvoeringstijd:
SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;
Hoofdoorzaken identificeren
Als het CPU-verbruik in het algemeen hoog is, kunnen de volgende hoofdoorzaken mogelijk zijn:
Langlopende transacties
Langlopende transacties kunnen CPU-resources verbruiken die kunnen leiden tot een hoog CPU-gebruik.
De volgende query helpt bij het identificeren van verbindingen die het langst worden uitgevoerd:
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;
Totaal aantal verbindingen en nummerverbindingen per status
Een groot aantal verbindingen met de database is ook een ander probleem dat kan leiden tot een verhoogd CPU- en geheugengebruik.
De volgende query geeft informatie over het aantal verbindingen per status:
SELECT state, count(*)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;
Hoog CPU-gebruik oplossen
Gebruik Uitleg analyseren, PG Bouncer, groepsgewijze verbindingen en het beëindigen van langlopende transacties om een hoog CPU-gebruik op te lossen.
Uitleg analyseren gebruiken
Zodra u de query kent die lange tijd wordt uitgevoerd, gebruikt u EXPLAIN om de query verder te onderzoeken en af te stemmen.
Raadpleeg Het plan uitleggen voor meer informatie over de opdracht EXPLAIN.
PGBouncer en groepsgewijze verbindingen
In situaties waarin er veel niet-actieve verbindingen of veel verbindingen zijn, die de CPU gebruiken, kunt u overwegen een verbindingspooler zoals PgBouncer te gebruiken.
Raadpleeg voor meer informatie over PgBouncer:
Azure Database for PostgreSQL flexibele server biedt PgBouncer als een ingebouwde oplossing voor groepsgewijze verbindingen. Zie PgBouncer voor meer informatie
Langlopende transacties beëindigen
U kunt overwegen om een langlopende transactie als optie te beëindigen.
Als u de PID van een sessie wilt beëindigen, moet u de PID detecteren met behulp van de volgende query:
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;
U kunt ook filteren op andere eigenschappen, zoals usename (gebruikersnaam), datname (databasenaam) enzovoort.
Zodra u de PID van de sessie hebt, kunt u deze beëindigen met behulp van de volgende query:
SELECT pg_terminate_backend(pid);
Vacuüm- en tabelstatistieken bewaken
Het up-to-date houden van tabelstatistieken helpt de prestaties van query's te verbeteren. Controleer of regelmatige automatischevacuuming wordt uitgevoerd.
Met de volgende query kunt u de tabellen identificeren die vacuüm nodig hebben:
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 en last_autoanalyze kolommen geven de datum en tijd aan waarop de tabel voor het laatst automatisch is ontruimd of geanalyseerd. Als de tabellen niet regelmatig worden opgezogen, voert u stappen uit om autovacuum af te stemmen. Zie Problemen met Autovacuum oplossen voor meer informatie over het oplossen en afstemmen van autovacuum.
Een kortetermijnoplossing is om een handmatige vacuümanalyse uit te voeren van de tabellen waarin trage query's worden gezien:
vacuum analyze <table_name>;