MySQL Performance Cheat Sheet

MySQL är omfattande och har massor av områden att optimera och justera för önskad prestanda. Vissa ändringar kan utföras dynamiskt, andra kräver omstart av servern. Det är ganska vanligt att hitta en MySQL-installation med en standardkonfiguration, även om den senare kanske inte är lämplig i sig utifrån din arbetsbelastning och inställningar.

Här är nyckelområdena i MySQL som jag har hämtat från olika expertkällor i MySQL-världen, samt våra egna erfarenheter här på Severalnines. Den här bloggen skulle fungera som ditt fuskblad för att trimma prestanda och göra din MySQL fantastisk igen :-)

Låt oss ta en titt på dessa genom att beskriva nyckelområdena i MySQL.

Systemvariabler

MySQL har massor av variabler som du kan överväga att ändra. Vissa variabler är dynamiska vilket innebär att de kan ställas in med hjälp av SET-satsen. Andra kräver omstart av servern efter att de har ställts in i konfigurationsfilen (t.ex. /etc/my.cnf, etc/mysql/my.cnf). Jag ska dock gå igenom de vanliga sakerna som är ganska vanliga att ställa in för att göra servern optimerad.

sort_buffer_size

Den här variabeln styr hur stor din filesort-buffert är, vilket innebär att när en fråga behöver sortera raderna, används värdet på denna variabel för att begränsa storleken som behöver allokeras. Observera att denna variabel är per fråga som bearbetas (eller per anslutning), vilket betyder att det skulle vara ett minneshungrigt när du ställer in detta högre och om du har flera anslutningar som kräver sortering av dina rader. Du kan dock övervaka dina behov genom att kontrollera den globala statusvariabeln Sort_merge_passes. Om detta värde är stort bör du överväga att öka värdet på systemvariabeln sort_buffer_size. Annars, ta det till den måttliga gränsen som du behöver. Om du ställer in detta för lågt eller om du har stora frågor att bearbeta, kan effekten av att sortera dina rader bli långsammare än förväntat eftersom data hämtas slumpmässigt vid diskdykning. Detta kan orsaka prestandaförsämring. Det är dock bäst att fixa dina frågor. Annars, om din applikation är designad för att dra stora frågor och kräver sortering, är det effektivt att använda verktyg som hanterar frågecache som Redis. Som standard, i MySQL 8.0, är ​​det aktuella värdet 256 KiB. Ställ in detta endast när du har frågor som är mycket använda eller anropssorter.

read_buffer_size

MySQL-dokumentationen nämner att för varje begäran som utför en sekventiell skanning av en tabell, allokerar den en läsbuffert. Systemvariabeln read_buffer_size bestämmer buffertstorleken. Den är också användbar för MyISAM, men den här variabeln påverkar också alla lagringsmotorer. För MEMORY-tabeller används den för att bestämma minnesblockstorleken.

I grund och botten allokerar varje tråd som gör en sekventiell genomsökning efter en MyISAM-tabell en buffert av denna storlek (i byte) för varje tabell som den skannar. Det gäller för alla lagringsmotorer (som inkluderar InnoDB), så det är användbart för frågor som sorterar rader med ORDER BY och cachelagrar dess index i en temporär fil. Om du gör många sekventiella skanningar, massinfoga i partitionstabeller, cachelagra resultat av kapslade frågor och överväg sedan att öka dess värde. Värdet på denna variabel bör vara en multipel av 4KB. Om det är inställt på ett värde som inte är en multipel av 4KB, kommer dess värde att avrundas nedåt till närmaste multipel av 4KB. Tänk på att om du ställer in detta till ett högre värde kommer det att förbruka en stor del av din servers minne. Jag föreslår att du inte använder detta utan korrekt benchmarking och övervakning av din miljö.

read_rnd_buffer_size

Denna variabel behandlar läsning av rader från en MyISAM-tabell i sorterad ordning efter en nyckelsorteringsoperation, raderna läses genom denna buffert för att undvika disksökningar. Dokumentationen säger att när rader läses i en godtycklig sekvens eller från en MyISAM-tabell i sorterad ordning efter en nyckelsorteringsoperation, läses raderna genom denna buffert (och bestäms genom denna buffertstorlek) för att undvika disksökningar. Att ställa in variabeln till ett stort värde kan förbättra ORDER BY-prestandan med ganska mycket. Detta är dock en buffert som allokeras för varje klient, så du bör inte ställa in den globala variabeln till ett stort värde. Ändra istället sessionsvariabeln endast från de klienter som behöver köra stora frågor. Du bör dock ta hänsyn till att detta inte gäller MariaDB, speciellt när du utnyttjar MRR. MariaDB använder mrr_buffer_size medan MySQL använder read_buffer_size read_rnd_buffer_size.

join_buffer_size

Som standard är värdet 256K. Den minsta storleken på bufferten som används för vanliga indexsökningar, intervallindexavsökningar och kopplingar som inte använder index och därmed utför fullständiga tabellsökningar. Används även av BKA-optimeringen (som är inaktiverad som standard). Öka dess värde för att få snabbare fullständiga anslutningar när det inte är möjligt att lägga till index. Varning kan dock vara minnesproblem om du ställer in detta för högt. Kom ihåg att en kopplingsbuffert tilldelas för varje full koppling mellan två tabeller. För en komplex koppling mellan flera tabeller för vilka index inte används, kan flera kopplingsbuffertar vara nödvändiga. Bäst lämnas lågt globalt och ställs in högt i sessioner (genom att använda SET SESSION-syntax) som kräver stora fullständiga anslutningar. På 64-bitarsplattformar trunkerar Windows värden över 4 GB till 4 GB-1 med en varning.

max_heap_table_size

Detta är den maximala storleken i byte för användarskapade MEMORY-tabeller som tillåts växa. Detta är användbart när din applikation hanterar MEMORY-lagringsmotortabeller. Att ställa in variabeln medan servern är aktiv har ingen effekt på befintliga tabeller om de inte återskapas eller ändras. Den minsta av max_heap_table_size och tmp_table_size begränsar också interna tabeller i minnet. Den här variabeln är också i kombination med tmp_table_size för att begränsa storleken på interna tabeller i minnet (detta skiljer sig från de tabeller som uttryckligen skapats som Engine=MEMORY eftersom den bara tillämpar max_heap_table_size), vilket som är mindre tillämpas mellan de två.

tmp_table_size

Den största storleken för temporära tabeller i minnet (inte MEMORY-tabeller) men om max_heap_table_size är mindre kommer den nedre gränsen att gälla. Om en temporär tabell i minnet överskrider gränsen, konverterar MySQL den automatiskt till en tillfällig tabell på disken. Öka värdet på tmp_table_size (och max_heap_table_size om det behövs) om du gör många avancerade GROUP BY-frågor och du har stort tillgängligt minnesutrymme. Du kan jämföra antalet interna temporära tabeller på disken som skapats med det totala antalet interna temporära tabeller som skapats genom att jämföra värdena för variablerna Created_tmp_disk_tables och Created_tmp_tables. I ClusterControl kan du övervaka detta via Dashboard -> Diagram över tillfälliga objekt.

table_open_cache

Du kan öka värdet på denna variabel om du har ett stort antal tabeller som ofta används i din datamängd. Den kommer att tillämpas för alla trådar, alltså per anslutningsbasis. Värdet anger det maximala antalet tabeller som servern kan hålla öppna i en tabellcacheinstans. Även om en ökning av detta värde ökar antalet filbeskrivningar som mysqld kräver, så du kan lika gärna överväga att kontrollera ditt open_files_limit-värde eller kontrollera hur stor gränsen MJUK och HÅR är som är inställd i ditt *nix-operativsystem. Du kan övervaka detta om du behöver öka tabellcachen genom att kontrollera statusvariabeln Opened_tables. Om värdet på Opened_tables är stort och du inte använder FLUSH TABLES ofta (vilket bara tvingar alla tabeller att stängas och öppnas igen), bör du öka värdet på variabeln table_open_cache. Om du har ett litet värde för table_open_cache, och ett stort antal tabeller används ofta, kan detta påverka prestanda på din server. Om du märker många poster i MySQL-processlistan med status "Öppningstabeller" eller "Stänger tabeller", är det dags att justera värdet på denna variabel men notera varningen som nämndes tidigare. I ClusterControl kan du kontrollera detta under Dashboards -> Table Open Cache Status eller Dashboards -> Öppna tabeller. Du kan kontrollera det här för mer information.

table_open_cache_instances

Att ställa in den här variabeln skulle bidra till att förbättra skalbarheten och naturligtvis prestanda vilket skulle minska konflikterna mellan sessioner. Värdet du anger här begränsar antalet öppna tabeller cache-instanser. Den öppna tabellcachen kan partitioneras i flera mindre cacheinstanser av storleken table_open_cache / table_open_cache_instances . En session behöver endast låsa en instans för att komma åt den för DML-satser. Detta segmenterar cacheåtkomst mellan instanser, vilket tillåter högre prestanda för operationer som använder cachen när det finns många sessioner som kommer åt tabeller. (DDL-satser kräver fortfarande ett lås på hela cachen, men sådana satser är mycket mindre frekventa än DML-satser.) Ett värde på 8 eller 16 rekommenderas på system som rutinmässigt använder 16 eller fler kärnor.

tabelldefinitionscache

Cachetabelldefinitioner, dvs det är här CREATE TABLE cachelagras för att påskynda öppningen av tabeller och endast en post per tabell. Det skulle vara rimligt att öka värdet om du har ett stort antal bord. Tabelldefinitionscachen tar mindre utrymme och använder inte fildeskriptorer, till skillnad från den vanliga tabellcachen. Peter Zaitsev från Percona föreslår om du kan prova inställningen av formeln nedan,

The number of user-defined tables + 10% unless 50K+ tables

Men tänk på att standardvärdet är baserat på följande formel med en gräns på 2000.

MIN(400 + table_open_cache / 2, 2000)

Så om du har ett större antal tabeller jämfört med standarden, är det rimligt att du ökar dess värde. Tänk på att med InnoDB används denna variabel som en mjuk gräns för antalet öppna tabellinstanser för dataordbokens cache. Den kommer att tillämpa LRU-mekanismen när den överskrider det aktuella värdet för denna variabel. Gränsen hjälper till att hantera situationer där betydande mängder minne skulle användas för att cachelagra sällan använda tabellinstanser tills nästa serverstart. Följaktligen placeras inte överordnade och underordnade tabellinstanser med främmande nyckelrelationer på LRU-listan och kan lägga på en högre gräns än gränsen definierad av table_definition_cache och är inte föremål för eviction i minnet under LRU. Dessutom definierar table_definition_cache en mjuk gräns för antalet InnoDB-fil-per-tabell-tabellutrymmen som kan vara öppna samtidigt, vilket också styrs av innodb_open_files och i själva verket används den högsta inställningen mellan dessa variabler, om båda är inställda . Om ingen av variablerna är inställd, används table_definition_cache, som har ett högre standardvärde. Om antalet öppna tabellutrymmesfilhandtag överskrider gränsen som definieras av table_definition_cache eller innodb_open_files, söker LRU-mekanismen i tabellutrymmesfilens LRU-lista efter filer som är helt rensade och för närvarande inte utökas. Denna process utförs varje gång ett nytt tabellutrymme öppnas. Om det inte finns några "inaktiva" tabellutrymmen stängs inga tabellutrymmesfiler. Så tänk på detta.

max_allowed_packet

Detta är den maximala storleken per anslutning för en SQL-fråga eller -rad som returneras. Värdet höjdes senast i MySQL 5.6. Men i MySQL 8.0 (åtminstone på 8.0.3) är det nuvarande standardvärdet 64 MiB. Du kan överväga att justera detta om du har stora BLOB-rader som behöver dras ut (eller läsas), annars kan du lämna dessa standardinställningar med 8.0 men i äldre versioner är standard 4 MiB så du kan ta hand om det ifall du stöter på ER_NET_PACKET_TOO_LARGE-fel. Det största möjliga paketet som kan överföras till eller från en MySQL 8.0-server eller klient är 1 GB.

max_anslutningar

Detta är antalet tillåtna anslutningar för din MySQL-server. Om du hittar felet i MySQL "För många anslutningar", kan du överväga att ställa in det högre. Som standard är värdet på 151 inte tillräckligt, särskilt på en produktionsdatabas, och med tanke på att du har större resurser på servern (slösa inte dina serverresurser, särskilt om det är en dedikerad MySQL-server). Du måste dock ha tillräckligt med filbeskrivningar annars kommer du få slut på dem. Överväg i så fall att justera din SOFT och HARD-gräns för dina *nix-operativsystem och ställ in ett högre värde på open_files_limit i MySQL (5000 är standardgränsen). Tänk på att det är mycket ofta att applikationen inte stänger anslutningar till databasen korrekt, och att ställa in en hög max_connections kan leda till att din server inte svarar eller blir hög. Att använda en anslutningspool på programnivå kan hjälpa till att lösa problemet här.

thread_cache_size

Detta är cachen för att förhindra överdriven trådskapande. När en klient kopplar från, läggs klientens trådar i cachen om det finns färre än thread_cache_size-trådar där. Begäran om trådar tillgodoses genom att om möjligt återanvända trådar som tagits från cachen, och endast när cachen är tom skapas en ny tråd. Denna variabel kan ökas för att förbättra prestandan om du har många nya anslutningar. Normalt ger detta ingen märkbar prestandaförbättring om du har en bra trådimplementering. Men om din server ser hundratals anslutningar per sekund bör du normalt ställa in thread_cache_size tillräckligt högt så att de flesta nya anslutningar använder cachade trådar. Genom att undersöka skillnaden mellan statusvariablerna Connections och Threads_created kan du se hur effektiv trådcachen är. Med formeln som anges i dokumentationen är 8 + (max_connections / 100) tillräckligt bra.

query_cache_size

För vissa inställningar är denna variabel deras värsta fiende. För vissa system som upplever hög belastning och är upptagna med höga läsningar, kommer den här variabeln att köra ner dig. Det har funnits riktmärken som var väl och testade av t.ex. Percona. Denna variabel måste också sättas till 0 tillsammans med query_cache_type =0 för att stänga av den. De goda nyheterna i MySQL 8.0 är att MySQL-teamet har slutat stödja detta, eftersom denna variabel verkligen kan orsaka prestandaproblem. Jag måste hålla med om deras blogg att det är osannolikt att det förbättrar förutsägbarheten av prestanda. Om du är engagerad i att använda frågecache, föreslår jag att du använder Redis eller ProxySQL.

Storage Engine - InnoDB

InnoDB är en ACID-kompatibel lagringsmotor med olika funktioner att erbjuda tillsammans med stöd för främmande nyckel (Declarative Referential Integrity). Detta har många saker att säga här men vissa variabler att överväga för justering:

innodb_buffer_pool_size

Denna variabel fungerar som en nyckelbuffert för MyISAM men den har massor av saker att erbjuda. Eftersom InnoDB är starkt beroende av buffertpoolen kan du överväga att ställa in det här värdet vanligtvis till 70%-80% av din servers minne. Det är också fördelaktigt att du har ett större minnesutrymme än din datauppsättning, och att ställa in ett högre värde för din buffertpool men inte för mycket. I ClusterControl kan detta övervakas med hjälp av våra Dashboards -> InnoDB Metrics -> InnoDB Buffer Pool Pages-diagram. Du kan också övervaka detta med VISA GLOBAL STATUS med hjälp av variablerna Innodb_buffer_pool_pages*.

innodb_buffer_pool_instances

För din samtidiga arbetsbelastning kan inställning av denna variabel förbättra samtidighet och minska konflikter som olika trådar av läs/skriv till cachade sidor. Minsta innodb_buffer_pool_instances bör ligga mellan 1 (minst) och 64 (maximalt). Varje sida som lagras i eller läses från buffertpoolen tilldelas en av buffertpoolsinstanserna slumpmässigt, med hjälp av en hashfunktion. Varje buffertpool hanterar sina egna lediga listor, tömningslistor, LRU:er och alla andra datastrukturer som är anslutna till en buffertpool och skyddas av sin egen buffertpoolsmutex. Observera att det här alternativet endast träder i kraft när innodb_buffer_pool_size>=1GiB och dess storlek är uppdelad mellan buffertpoolsinstanserna.

innodb_log_file_size

Denna variabel är loggfilen i en logggrupp. Den kombinerade storleken på loggfiler (innodb_log_file_size * innodb_log_files_in_group) får inte överstiga ett maximalt värde som är något mindre än 512 GB. Enligt Vadim är en större loggfilstorlek bättre för prestanda, men den har en nackdel (en betydande sådan) som du behöver oroa dig för:återställningstiden efter en krasch. Du måste balansera återhämtningstiden i den sällsynta händelsen av en kraschåterställning mot att maximera genomströmningen under toppdrift. Denna begränsning kan översättas till en 20 gånger längre kraschåterställningsprocess!

För att utveckla det skulle ett högre värde vara bra för InnoDB transaktionsloggar och är avgörande för bra och stabil skrivprestanda. Ju högre värde, desto mindre kontrollpunktsspolningsaktivitet krävs i buffertpoolen, vilket sparar disk I/O. Återställningsprocessen är dock ganska långsam när din databas stängdes av onormalt (krascha eller dödas, antingen OOM eller oavsiktlig). Helst kan du ha 1-2GiB i produktion men självklart kan du justera detta. Att benchmarka dessa förändringar kan vara en stor fördel för att se hur den fungerar, särskilt efter en krasch.

innodb_log_buffer_size

För att spara disk I/O, skriver InnoDB:s ändringsdata till dess loggbuffert och den använder värdet på innodb_log_buffer_size med ett standardvärde på 8MiB. Detta är fördelaktigt speciellt för stora transaktioner eftersom det inte behöver skriva loggen över ändringar till disken innan transaktionen genomförs. Om din skrivtrafik är för hög (infogar, raderar, uppdaterar) sparas disk I/O om du gör bufferten större.

innodb_flush_log_at_trx_commit

När innodb_flush_log_at_trx_commit är satt till 1 töms loggbufferten vid varje transaktionsbekräftelse till loggfilen på disken och ger maximal dataintegritet men det har också prestandapåverkan. Om du ställer in den på 2 betyder det att loggbufferten töms till OS-filcachen vid varje transaktionsföring. Innebörden av 2 är optimal och förbättrar prestandan om du kan sänka dina ACID-krav och har råd att förlora transaktioner under den sista sekunden eller två i händelse av OS-krascher.

innodb_thread_concurrency

Med förbättringar av InnoDB-motorn rekommenderas det att låta motorn kontrollera samtidigheten genom att hålla den till standardvärdet (som är noll). Om du ser samtidighetsproblem kan du ställa in denna variabel. Ett rekommenderat värde är 2 gånger antalet processorer plus antalet diskar. Dess dynamiska variabel betyder att den kan ställas in utan att starta om MySQL-servern.

innodb_flush_method

Denna variabel måste dock prövas och testas på vilken hårdvara som passar dig bäst. Om du använder en RAID med batteristödd cache hjälper DIRECT_IO till att lindra I/O-trycket. Direct I/O cachelagras inte så det undviker dubbelbuffring med buffertpool och filsystemcache. Om din disk är lagrad i SAN kan O_DSYNC vara snabbare för en lästung arbetsbelastning med mestadels SELECT-satser.

innodb_file_per_table

innodb_file_per_table är PÅ som standard från MySQL 5.6. Detta rekommenderas vanligtvis eftersom det undviker att ha ett stort delat bordsutrymme och eftersom det låter dig ta tillbaka utrymme när du släpper eller trunkerar ett bord. Separat tabellutrymme är också fördelaktigt för Xtrabackup partiell säkerhetskopiering.

innodb_stats_on_metadata

Detta försöker hålla andelen smutsiga sidor under kontroll, och innan Innodb-pluginet var detta verkligen det enda sättet att ställa in smutsad buffertspolning. Däremot har jag sett servrar med 3% smutsiga buffertar och de når sin maximala checkpointålder. Sättet som detta ökar smutsig buffertspolning skalar inte heller bra på hög io-undersystem, det fördubblar i praktiken bara smutsbuffertspolningen per sekund när procentandelen smutsiga sidor överstiger denna mängd.

innodb_io_capacity

Den här inställningen, trots alla våra stora förhoppningar om att den skulle tillåta Innodb att bättre använda vår IO i alla operationer, kontrollerar helt enkelt mängden smutsad spolning av sidor per sekund (och andra bakgrundsuppgifter som att läsa framåt). Gör det här större, du spolar mer per sekund. Detta anpassar sig inte, det gör helt enkelt så många iops varje sekund om det finns smutsiga buffertar att spola. Det kommer effektivt att eliminera all optimering av IO-konsolidering om du har en tillräckligt låg skrivbelastning (det vill säga, smutsiga sidor rensas nästan omedelbart, vi kan ha det bättre utan en transaktionslogg i det här fallet). Det kan också snabbt svälta data som läser och skriver till transaktionsloggen om du ställer in detta för högt.

innodb_write_io_threads

Styr hur många trådar som ska ha pågående skrivningar till disken. Jag är inte säker på varför detta fortfarande är användbart om du kan använda Linux-native AIO. Dessa kan också göras oanvändbara av filsystem som inte tillåter parallell skrivning till samma fil med mer än en tråd (särskilt om du har relativt få tabeller och/eller använder de globala tabellutrymmena)

innodb_adaptive_flushing

Anger om hastigheten för att tömma smutsiga sidor i InnoDB-buffertpoolen ska justeras dynamiskt baserat på arbetsbelastningen. Att justera spolhastigheten dynamiskt är avsedd att undvika skurar av I/O-aktivitet. Vanligtvis är detta aktiverat som standard . Den här variabeln, när den är aktiverad, försöker vara smartare när det gäller att spola mer aggressivt baserat på antalet smutsiga sidor och takten för tillväxten i transaktionsloggen.

innodb_dedicated_server

Denna variabel är ny i MySQL 8.0 som tillämpas globalt och kräver en omstart av MySQL eftersom det inte är en dynamisk variabel. Men eftersom dokumentationen säger att denna variabel endast är önskvärd om din MySQL körs på en dedikerad server. Annars, aktivera inte detta på en delad värd eller delar systemresurser med andra applikationer. När detta är aktiverat kommer InnoDB att göra en automatisk konfiguration för mängden minne som detekteras för variablerna innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. Nackdelen är bara att du inte har möjlighet att tillämpa dina önskade värden på de upptäckta variablerna som nämns.

MyISAM

key_buffer_size

InnoDB är standardlagringsmotorn för MySQL nu, standarden för key_buffer_size kan förmodligen minskas om du inte använder MyISAM produktivt som en del av din applikation (men vem använder MyISAM i produktionen nu?). Jag skulle här föreslå att du ställer in kanske 1 % RAM-minne eller 256 MiB i början om du har större minne och dedikerar det återstående minnet för din OS-cache och InnoDB-buffertpool.

Övriga bestämmelser för prestanda

slow_query_log

Naturligtvis hjälper den här variabeln inte att öka din MySQL-server. Den här variabeln kan dock hjälpa dig att analysera långsamma sökningar. Värdet kan ställas in på 0 eller AV för att inaktivera loggning. Ställ in den på 1 eller ON för att aktivera detta. Standardvärdet beror på om alternativet --slow_query_log är givet. Destinationen för loggutgång styrs av systemvariabeln log_output; om det värdet är NONE skrivs inga loggposter även om loggen är aktiverad. Du kan ange filnamnet eller destinationen för frågeloggfilen genom att ställa in variabeln slow_query_log_file.

long_query_time

Om en fråga tar längre tid än så många sekunder, ökar servern statusvariabeln Slow_queries. Om den långsamma frågeloggen är aktiverad loggas frågan till den långsamma frågeloggfilen. Detta värde mäts i realtid, inte CPU-tid, så en fråga som ligger under tröskeln på ett lätt belastat system kan vara över tröskeln på ett hårt belastat. Minsta och standardvärden för long_query_time är 0 respektive 10. Observera också att om variabeln min_examined_row_limit är inställd på> 0, loggar den inte frågor även om det tar för lång tid om antalet returnerade rader är mindre än värdet i min_examined_row_limit.

För mer information om hur du ställer in din långsamma frågeloggning, se dokumentationen här.

sync_binlog

Denna variabel styr hur ofta MySQL kommer att synkronisera binlogs till disken. Som standard (>=5.7.7) är detta inställt på 1 vilket betyder att det synkroniseras till disken innan transaktioner genomförs. Detta medför dock en negativ inverkan på prestandan på grund av ökat antal skrivningar. Men detta är den säkraste inställningen om du vill ha strikt ACID-kompatibel tillsammans med dina slavar. Alternativt kan du ställa in detta till 0 om du vill inaktivera disksynkronisering och bara lita på att operativsystemet spolar den binära loggen till disk då och då. Om du ställer in den högre än 1 betyder det att binloggen synkroniseras till disk efter att N binära log-commit-grupper har samlats in, där N är> 1.

Dumpa/återställ buffertpool

Det är ganska vanligt att din produktionsdatabas behöver värmas upp från en kallstart/omstart. Genom att dumpa den aktuella buffertpoolen före en omstart, skulle den spara innehållet från buffertpoolen och när den väl är uppe kommer den att ladda tillbaka innehållet till buffertpoolen. På så sätt undviker detta behovet av att värma upp din databas tillbaka till cachen. Observera att den här versionen sedan introducerades i 5.6 men Percona Server 5.5 har den redan tillgänglig, ifall du undrar. För att aktivera den här funktionen, ställ in båda variablerna innodb_buffer_pool_dump_at_shutdown =PÅ och innodb_buffer_pool_load_at_startup =PÅ.

Hårdvara

Vi är nu inne i 2019, det har skett många nya hårdvaruförbättringar. Vanligtvis finns det inga hårda krav på att MySQL skulle kräva en specifik hårdvara, men detta beror på vad du behöver databasen för att göra. Jag förväntar mig att du inte läser den här bloggen eftersom du gör ett test om den körs på en Intel Pentium 200 MHz.

För CPU kommer snabbare processorer med flera kärnor att vara optimala för MySQL i de senaste versionerna åtminstone sedan 5.6. Intels Xeon/Itanium-processorer kan vara dyra men testade för skalbara och pålitliga datorplattformar. Amazon har skickat sina EC2-instanser som körs på ARM-arkitektur. Även om jag personligen inte har provat att köra eller komma ihåg att köra MySQL på ARM-arkitektur, finns det riktmärken som hade gjorts för flera år sedan. Moderna processorer kan skala sina frekvenser upp och ner baserat på temperatur, belastning och energisparpolicy för OS. Det finns dock en chans att dina CPU-inställningar i ditt Linux OS är inställda på en annan guvernör. Du kan kolla upp det eller ställa in med "prestanda"-guvernören genom att göra följande:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

För Memory är det mycket viktigt att ditt minne är stort och kan likställa storleken på din datauppsättning. Se till att du har swappiness =1. Du kan kolla upp det genom att kolla sysctl eller kolla filen i procfs. Detta uppnås genom att göra följande:

$ sysctl -e vm.swappiness
vm.swappiness = 1

Eller ställ in det till ett värde på 1 enligt följande

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

En annan bra sak att tänka på för din minneshantering är att överväga att stänga av THP (Transparrent Huge Pages). Tidigare minns jag att vi har några konstiga problem med CPU-användning och trodde att det berodde på disk I/O. Det visade sig att problemet låg i kärnan khugepaged tråd som allokerar minne dynamiskt under körning. Inte bara detta, när kärnan går till defragmentering kommer ditt minne snabbt att tilldelas när det skickar det till THP. Standard HugePages-minne är förallokerat vid start och ändras inte under körning. Du kan verifiera och inaktivera detta genom att göra följande:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

För Disk är det viktigt att du har en bra genomströmning. Att använda RAID10 är den bästa inställningen för en databas med en batteribackupenhet. Med tillkomsten av flashenheter som erbjuder hög diskgenomströmning och hög disk I/O för läsning/skrivning, är det viktigt att det kan hantera det höga diskutnyttjandet och disk I/O.

Operativsystem

De flesta produktionssystem som körs på MySQL körs på Linux. Det beror på att MySQL hade testats och riktmärkts på Linux, och det låter som att det är de facto-standarden för en MySQL-installation. Men naturligtvis finns det inget som hindrar dig från att använda den på Unix- eller Windows-plattformen. Det skulle vara enklare om din plattform har testats och det finns en bred community som kan hjälpa dig, om du skulle få problem. De flesta inställningar körs på RHEL/Centos/Fedora och Debian/Ubuntu-system. I AWS har Amazon sin Amazon Linux som jag ser som används i produktionen av vissa.

Det viktigaste att tänka på med din installation är att ditt filsystem använder antingen XFS eller Ext4. För visst finns det för- och nackdelar mellan dessa två filsystem men jag kommer inte att gå till detaljerna här. Vissa säger att XFS överträffar Ext4 men det finns också rapporter om att Ext4 överträffar XFS. ZFS kommer också ur bilden som en bra kandidat för ett alternativt filsystem. Jervin Real (från Percona) har en fantastisk resurs på denna, du kan kolla den här presentationen under ZFS-konferensen.

Externa länkar

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA