Dela via

Felsöka problem med lite minne i Azure Database for MySQL – flexibel server

  • Artikel

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

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

För att säkerställa att en Azure Database for MySQL Flexible Server-instans presterar optimalt är det mycket viktigt att ha rätt minnesallokering och användning. När du skapar en instans av Azure Database for MySQL – flexibel server är det tillgängliga fysiska minnet som standard beroende på vilken nivå och storlek du väljer för din arbetsbelastning. Dessutom allokeras minne för buffertar och cacheminnen för att förbättra databasåtgärderna. Mer information finns i Hur MySQL använder minne.

Observera att Azure Database for MySQL – flexibel server förbrukar minne för att uppnå så mycket cache som möjligt. Därför kan minnesanvändning ofta hovra mellan 80 och 90 % av det tillgängliga fysiska minnet för en instans. Om det inte finns ett problem med förloppet för frågearbetsbelastningen är det inget problem. Du kan dock stöta på minnesproblem av orsaker som att du har:

  • Konfigurerade för stora buffertar.
  • Suboptimala frågor som körs.
  • Frågor som utför kopplingar och sorterar stora datamängder.
  • Ange maximalt antal anslutningar på en databasserver som är för hög.

En majoritet av en servers minne används av InnoDB:s globala buffertar och cacheminnen, som omfattar komponenter som innodb_buffer_pool_size, innodb_log_buffer_size, key_buffer_size och query_cache_size.

Värdet för parametern innodb_buffer_pool_size anger det minnesområde där InnoDB cachelagrar databastabellerna och indexrelaterade data. MySQL försöker hantera så mycket tabell- och indexrelaterade data i buffertpoolen som möjligt. En större buffertpool kräver att färre I/O-åtgärder omdirigeras till disken.

Övervaka minnesanvändning

Azure Database for MySQL – flexibel server innehåller ett antal mått för att mäta prestanda för din databasinstans. För att bättre förstå minnesanvändningen för databasservern kan du visa måtten Värdminnesprocent eller Minnesprocent .

Visa mått för minnesanvändning.

Om du märker att minnesanvändningen plötsligt har ökat och att det tillgängliga minnet sjunker snabbt övervakar du andra mått, till exempel Värdprocessorprocent, Totalt antal anslutningar och I/O-procent, för att avgöra om en plötslig topp i arbetsbelastningen är orsaken till problemet.

Observera att varje anslutning som upprättas med databasservern kräver allokering av en viss mängd minne. Därför kan en ökning av databasanslutningarna orsaka minnesbrist.

Orsaker till hög minnesanvändning

Nu ska vi titta på några fler orsaker till hög minnesanvändning i MySQL. Dessa orsaker beror på arbetsbelastningens egenskaper.

En ökning av temporära tabeller

MySQL använder "temporära tabeller", som är en särskild typ av tabell som är utformad för att lagra en tillfällig resultatuppsättning. Temporära tabeller kan återanvändas flera gånger under en session. Eftersom alla temporära tabeller som skapas är lokala för en session kan olika sessioner ha olika temporära tabeller. I produktionssystem med många sessioner som utför kompileringar av stora tillfälliga resultatuppsättningar bör du regelbundet kontrollera den globala statusräknaren created_tmp_tables, som spårar antalet tillfälliga tabeller som skapas under hög belastning. Ett stort antal minnesinterna temporära tabeller kan snabbt leda till lite ledigt minne i en instans av Azure Database for MySQL – flexibel server.

Med MySQL bestäms den tillfälliga tabellstorleken av värdena för två parametrar, enligt beskrivningen i följande tabell.

Parameter Beskrivning
tmp_table_size Anger den maximala storleken på interna, minnesinterna temporära tabeller.
max_heap_table_size Anger den maximala storlek som användarskapade MINNEStabeller kan utökas till.

Kommentar

När mySQL fastställer den maximala storleken på en intern, minnesintern tillfällig tabell tar mySQL hänsyn till den lägre av de värden som angetts för parametrarna tmp_table_size och max_heap_table_size.

Rekommendationer

Om du vill felsöka problem med lite minne som rör temporära tabeller bör du överväga följande rekommendationer.

  • Innan du ökar värdet för tmp_table_size kontrollerar du att databasen är korrekt indexerad, särskilt för kolumner som ingår i kopplingar och grupperas efter åtgärder. Om du använder lämpliga index i underliggande tabeller begränsas antalet temporära tabeller som skapas. Om du ökar värdet för den här parametern och parametern max_heap_table_size utan att verifiera dina index kan ineffektiva frågor köras utan index och skapa fler temporära tabeller än vad som är nödvändigt.
  • Justera värdena för parametrarna max_heap_table_size och tmp_table_size för att uppfylla arbetsbelastningens behov.
  • Om värdena som du anger för parametrarna max_heap_table_size och tmp_table_size är för låga kan temporära tabeller regelbundet spillas ut till lagringen, vilket ger svarstid till dina frågor. Du kan spåra temporära tabeller som spills till disken med hjälp av den globala statusräknaren created_tmp_disk_tables. Genom att jämföra värdena för variablerna created_tmp_disk_tables och created_tmp_tables visar du antalet interna temporära tabeller på disk som har skapats med det totala antalet interna temporära tabeller som skapats.

Tabellcache

Som ett system med flera trådar upprätthåller MySQL en cache med tabellfilbeskrivningar så att tabellerna kan öppnas separat av flera sessioner samtidigt. MySQL använder en del minnes- och OS-filbeskrivningar för att underhålla den här tabellcachen. Variabeln table_open_cache definierar storleken på tabellcachen.

Rekommendationer

Om du vill felsöka problem med lite minne som rör tabellcachen bör du överväga följande rekommendationer.

  • Parametern table_open_cache anger antalet öppna tabeller för alla trådar. Om du ökar det här värdet ökar antalet filbeskrivningar som mysqld kräver. Du kan kontrollera om du behöver öka tabellcachen genom att kontrollera opened_tables statusvariabeln i visa global statusräknare. Öka värdet för den här parametern i steg för att hantera din arbetsbelastning.
  • Om du anger table_open_cache för låg kan Azure Database for MySQL – flexibel server ägna mer tid åt att öppna och stänga tabeller som behövs för frågebearbetning.
  • Om du ställer in det här värdet för högt kan användningen av mer minne och operativsystemet som körs av filbeskrivningar leda till nekade anslutningar eller misslyckas med att bearbeta frågor.

Andra buffertar och frågecachen

När du felsöker problem som rör minnesbrist kan du arbeta med några fler buffertar och en cache för att hjälpa till med lösningen.

Nätbuffert (net_buffer_length)

Nätbufferten är storlek för anslutnings- och trådbuffertar för varje klienttråd och kan växa till det värde som anges för max_allowed_packet. Om en frågeinstruktor är stor, till exempel, har alla infogningar/uppdateringar ett mycket stort värde. Om du ökar värdet för parametern net_buffer_length kan du förbättra prestandan.

Kopplingsbuffert (join_buffer_size)

Kopplingsbufferten allokeras till cachetabellrader när en koppling inte kan använda ett index. Om databasen har många kopplingar som utförs utan index kan du överväga att lägga till index för snabbare kopplingar. Om du inte kan lägga till index kan du överväga att öka värdet för parametern join_buffer_size, vilket anger mängden minne som allokeras per anslutning.

Sorteringsbuffert (sort_buffer_size)

Sorteringsbufferten används för att utföra sortering för vissa ORDER BY- och GROUP BY-frågor. Om du ser många Sort_merge_passes per sekund i SHOW GLOBAL STATUS-utdata bör du överväga att öka sort_buffer_size värdet för att påskynda ORDER BY- eller GROUP BY-åtgärder som inte kan förbättras med hjälp av frågeoptimering eller bättre indexering.

Undvik att godtyckligt öka sort_buffer_size-värdet om du inte har relaterad information som anger något annat. Minne för den här bufferten tilldelas per anslutning. I MySQL-dokumentationen visar artikeln ServerSystemvariabler att det i Linux finns två tröskelvärden, 256 KB och 2 MB, och att användning av större värden kan göra minnesallokeringen betydligt långsammare. Undvik därför att öka sort_buffer_size värdet utöver 2 miljoner, eftersom prestandastraffet överväger eventuella fördelar.

Frågecache (query_cache_size)

Frågecachen är ett minnesområde som används för att cachelagra frågeresultatuppsättningar. Parametern query_cache_size avgör hur mycket minne som allokeras för cachelagring av frågeresultat. Som standard är frågecachen inaktiverad. Dessutom är frågecachen inaktuell i MySQL version 5.7.20 och tas bort i MySQL version 8.0. Om frågecachen för närvarande är aktiverad i din lösning kontrollerar du att det inte finns några frågor som förlitar sig på den innan du inaktiverar den.

Beräkna buffertcachens träffförhållande

Kvot för buffertcacheträff är viktigt i Azure Database for MySQL–miljön för flexibel server för att förstå om buffertpoolen kan hantera arbetsbelastningsbegäranden eller inte, och som en allmän tumregel är det en bra idé att alltid ha en buffertpoolscacheträffkvot på mer än 99 %.

För att beräkna innoDB-buffertpoolens träffkvot för läsbegäranden kan du köra VISA GLOBAL STATUS för att hämta räknarna "Innodb_buffer_pool_read_requests" och "Innodb_buffer_pool_reads" och sedan beräkna värdet med hjälp av formeln som visas nedan.

InnoDB Buffer pool hit ratio = Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads) * 100

Betänk följande exempel.

mysql> show global status like "innodb_buffer_pool_reads";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Innodb_buffer_pool_reads | 197   |
+--------------------------+-------+
1 row in set (0.00 sec)

mysql> show global status like "innodb_buffer_pool_read_requests";
+----------------------------------+----------+
| Variable_name                    | Value    |
+----------------------------------+----------+
| Innodb_buffer_pool_read_requests | 22479167 |
+----------------------------------+----------+
1 row in set (0.00 sec)

Med hjälp av ovanstående värden ger databehandling av InnoDB-buffertpoolens träffkvot för läsbegäranden följande resultat:

InnoDB Buffer pool hit ratio = 22479167/(22479167+197) * 100 

Buffer hit ratio = 99.99%

Förutom att välja uttryck buffert cache träffförhållande, för alla DML-uttryck, skrivningar till InnoDB Buffer Pool sker i bakgrunden. Men om det är nödvändigt att läsa eller skapa en sida och inga rena sidor är tillgängliga, är det också nödvändigt att vänta tills sidorna rensas först.

Räknaren Innodb_buffer_pool_wait_free räknar hur många gånger detta har hänt. Innodb_buffer_pool_wait_free större än 0 är en stark indikator på att InnoDB-buffertpoolen är för liten och att en ökning av buffertpoolens storlek eller instansstorlek krävs för att hantera skrivningar som kommer till databasen.

Rekommendationer

  • Kontrollera att databasen har tillräckligt med resurser allokerade för att köra dina frågor. Ibland kan du behöva skala upp instansstorleken för att få mer fysiskt minne så att buffertar och cacheminnen passar din arbetsbelastning.
  • Undvik stora eller långvariga transaktioner genom att dela upp dem i mindre transaktioner.
  • Använd aviseringar "Värdminnesprocent" så att du får meddelanden om systemet överskrider något av de angivna tröskelvärdena.
  • Använd Query Performance Insights eller Azure-arbetsböcker för att identifiera eventuella problematiska eller långsamt körande frågor och sedan optimera dem.
  • För produktionsdatabasservrar samlar du in diagnostik med jämna mellanrum för att säkerställa att allt fungerar smidigt. Annars kan du felsöka och lösa eventuella problem som du identifierar.

Nästa steg

Om du vill hitta peer-svar på dina viktigaste frågor eller för att publicera eller besvara en fråga går du till Stack Overflow.