Dela via

Felsöka hög IOPS-användning för Azure Database for PostgreSQL – flexibel server

  • Artikel

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

Den här artikeln visar hur du snabbt identifierar rotorsaken till hög IOPS-användning (in-/utdataåtgärder per sekund) och tillhandahåller åtgärder för att kontrollera IOPS-användningen när du använder en flexibel Azure Database for PostgreSQL-server.

I den här artikeln kan du se hur du:

  • Om felsökningsguider för att identifiera och få rekommendationer för att minimera rotorsaker.
  • Använd verktyg för att identifiera hög användning av indata/utdata (I/O), till exempel Azure Metrics, Query Store och pg_stat_statements.
  • Identifiera rotorsaker, till exempel långvariga frågor, tidsinställningar för kontrollpunkter, en störande autovacuum-daemonprocess och hög lagringsanvändning.
  • Lös hög I/O-användning med hjälp av Förklara analysera, justera kontrollpunktsrelaterade serverparametrar och justera autovacuum-daemonen.

Felsökningsguider

Med hjälp av funktionsfelsökningsguiderna som är tillgängliga på Azure Database for PostgreSQL–portalen för flexibel server kan du hitta den troliga rotorsaken och rekommendationerna till scenariot för att minimera hög IOPS-användning. Så här konfigurerar du felsökningsguiderna för att använda dem genom att följa felsökningsguiderna för installation.

Verktyg för att identifiera hög I/O-användning

Överväg följande verktyg för att identifiera hög I/O-användning.

Azure-mått

Azure Metrics är en bra startpunkt för att kontrollera I/O-användning för ett definierat datum och en viss period. Mått ger information om den tid då I/O-användningen är hög. Jämför graferna för skriv-IOPS, Läs IOPS, Läs dataflöde och Skriv dataflöde för att ta reda på tider när arbetsbelastningen orsakar hög I/O-användning. För proaktiv övervakning kan du konfigurera aviseringar för måtten. Stegvis vägledning finns i Azure Metrics.

Query Store

Funktionen Query Store samlar automatiskt in historiken för frågor och körningsstatistik och behåller dem för din granskning. Data segmenteras efter tid för att 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. Stegvis vägledning finns i Övervaka prestanda med Query Store.

Använd följande instruktion för att visa de fem främsta SQL-uttrycken som använder I/O:

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

Tillägget pg_stat_statements

Tillägget pg_stat_statements hjälper till att identifiera frågor som använder I/O på servern.

Använd följande instruktion för att visa de fem främsta SQL-uttrycken som använder I/O:

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

Kommentar

När du använder frågearkivet eller pg_stat_statements för kolumner blk_read_time och blk_write_time ska fyllas i måste du aktivera serverparametern track_io_timing. Mer information om track_io_timingfinns i Serverparametrar.

Identifiera rotorsaker

Om I/O-förbrukningsnivåerna är höga i allmänhet kan följande vara rotorsakerna:

Långvariga transaktioner

Långvariga transaktioner kan förbruka I/O, vilket kan leda till hög I/O-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;

Tidsinställningar för kontrollpunkt

Hög I/O kan också ses i scenarier där en kontrollpunkt sker för ofta. Ett sätt att identifiera detta är genom att kontrollera loggfilen för Azure Database for PostgreSQL för flexibel server för följande loggtext: "LOG: checkpoints are occurring too frequently."

Du kan också undersöka med hjälp av en metod där periodiska ögonblicksbilder av pg_stat_bgwriter med en tidsstämpel sparas. Genom att använda de sparade ögonblicksbilderna kan du beräkna det genomsnittliga kontrollpunktsintervallet, antalet begärda kontrollpunkter och antalet tidsberäknade kontrollpunkter.

Störande autovacuum-daemonprocess

Kör följande fråga för att övervaka 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;

Frågan används för att kontrollera hur ofta tabellerna i databasen dammsugs.

  • last_autovacuum: Datum och tid då den senaste autovacuum kördes i tabellen.
  • autovacuum_count: Antalet gånger tabellen dammsugs.
  • autoanalyze_count: Antalet gånger tabellen analyserades.

Lösa hög I/O-användning

För att lösa hög I/O-användning kan du använda någon av följande tre metoder.

Kommandot EXPLAIN ANALYZE

När du har identifierat frågan som förbrukar hög I/O använder EXPLAIN ANALYZE du för att undersöka frågan ytterligare och finjustera den. Mer information om kommandot finns i EXPLAIN ANALYZE EXPLAIN-planen.

Avsluta långvariga transaktioner

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

Om du vill avsluta en sessions process-ID (PID) måste du identifiera PID:t 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, till exempel usename (användarnamn) eller datname (databasnamn).

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

SELECT pg_terminate_backend(pid);

Justera serverparametrar

Om du ser att kontrollpunkten sker för ofta ökar max_wal_size du serverparametern tills de flesta kontrollpunkter är tidsdrivna i stället för begärda. Slutligen bör 90 procent eller mer vara tidsbaserade, och intervallet mellan två kontrollpunkter bör ligga nära det checkpoint_timeout värde som anges på servern.

  • max_wal_size: Tider med hög belastning är ett bra tillfälle att komma fram till ett max_wal_size värde. Gör följande för att komma fram till ett värde:

    1. Kör följande fråga för att hämta aktuell WAL LSN och notera sedan resultatet:

      select pg_current_wal_lsn();

    2. Vänta ett checkpoint_timeout antal sekunder. Kör följande fråga för att hämta aktuell WAL LSN och notera sedan resultatet:

      select pg_current_wal_lsn();

    3. Kör följande fråga, som använder de två resultaten, för att kontrollera skillnaden i gigabyte (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: En bra idé är att ange värdet till 0,9. Ett värde på 0,9 på checkpoint_timeout 5 minuter indikerar till exempel att målet för att slutföra en kontrollpunkt är 270 sekunder (0,9*300 sekunder). Värdet 0,9 ger en ganska konsekvent I/O-belastning. Ett aggressivt värde checkpoint_completion_target för kan leda till en ökad I/O-belastning på servern.

  • checkpoint_timeout: Du kan öka checkpoint_timeout värdet från standardvärdet som anges på servern. När du ökar värdet bör du ta hänsyn till att en ökning av det också skulle öka tiden för kraschåterställning.

Justera autovacuum för att minska störningar

Mer information om övervakning och justering i scenarier där autovacuum är för störande finns i Autovacuum-justering.

Öka lagringen

Att öka lagringen hjälper när du lägger till mer IOPS på servern. Mer information om lagring och tillhörande IOPS finns i Beräknings- och lagringsalternativ.

Relaterat innehåll