Databasprestandajustering för MariaDB

Ända sedan MySQL ursprungligen bildades för att bilda MariaDB har det fått ett brett stöd och snabbt använts av en stor publik i databasen med öppen källkod. Ursprungligen en drop-in ersättare, MariaDB har börjat skapa skillnad mot MySQL, särskilt med releasen av MariaDB 10.2.

Trots detta finns det fortfarande ingen verklig skillnad mellan MariaDB och MySQL, eftersom båda har motorer som är kompatibla och kan köras inbyggt med varandra. Så bli inte förvånad om justeringen av din MariaDB-inställning har en liknande metod för en tuning MySQL.

Den här bloggen kommer att diskutera inställningen av MariaDB, speciellt de system som körs i en Linux-miljö.

MariaDB hårdvara och systemoptimering

MariaDB rekommenderar att du förbättrar din hårdvara i följande prioritetsordning...

Minne

Minne är den viktigaste faktorn för databaser eftersom det låter dig justera serversystemvariablerna. Mer minne betyder större nyckel- och tabellcacher, som lagras i minnet så att diskar kan komma åt, en storleksordning långsammare, reduceras därefter.

Kom dock ihåg att att bara lägga till mer minne kanske inte leder till drastiska förbättringar om servervariablerna inte är inställda på att använda det extra tillgängliga minnet.

Användning av fler RAM-platser på moderkortet ökar bussfrekvensen, och det blir mer latens mellan RAM och CPU. Det betyder att det är att föredra att använda den högsta RAM-storleken per plats.

Diskar

Snabb diskåtkomst är avgörande, eftersom det i slutändan är där data finns. Nyckeltalet är disksökningstiden (ett mått på hur snabbt den fysiska disken kan röra sig för att komma åt data) så välj diskar med så låg söktid som möjligt. Du kan också lägga till dedikerade diskar för temporära filer och transaktionsloggar.

Snabb Ethernet

Med lämpliga krav för din internetbandbredd betyder snabb ethernet att det kan ha snabbare svar på klientförfrågningar, replikeringssvarstid för att läsa binära loggar över slavarna, snabbare svarstider är också mycket viktigt, särskilt på Galera -baserade kluster.

CPU

Även om hårdvaruflaskhalsar ofta faller någon annanstans, gör snabbare processorer att beräkningar kan utföras snabbare och resultaten skickas tillbaka till klienten snabbare. Förutom processorhastighet är även processorns busshastighet och cachestorlek viktiga faktorer att ta hänsyn till.

Ställa in din Disk I/O Scheduler

I/O-schemaläggare finns som ett sätt att optimera begäranden om diskåtkomst. Den slår samman I/O-förfrågningar till liknande platser på disken. Detta innebär att hårddisken inte behöver söka så ofta och förbättrar en enorm övergripande svarstid och sparar diskoperationer. De rekommenderade värdena för I/O-prestanda är noop och deadline.

noop är användbart för att kontrollera om komplexa I/O-schemaläggningsbeslut från andra schemaläggare inte orsakar I/O-prestandaregressioner. I vissa fall kan det vara användbart för enheter som gör I/O-schemaläggning själva, som intelligent lagring, eller enheter som inte är beroende av mekanisk rörelse, som SSD:er. Vanligtvis är DEADLINE I/O-schemaläggaren ett bättre val för dessa enheter, men på grund av mindre overhead kan NOOP ge bättre prestanda på vissa arbetsbelastningar.

För deadline är det en latensorienterad I/O-schemaläggare. Varje I/O-förfrågan har en deadline tilldelad. Vanligtvis lagras förfrågningar i köer (läs och skriv) sorterade efter sektornummer. DEADLINE-algoritmen upprätthåller ytterligare två köer (läs och skriv) där förfrågningarna sorteras efter deadline. Så länge ingen förfrågan har gått ut, används "sektorskön". Om timeout inträffar, serveras förfrågningar från "deadline"-kön tills det inte finns några fler förfallna förfrågningar. Generellt sett föredrar algoritmen läsning framför skrivning.

För PCIe-enheter (NVMe SSD-enheter) har de sina egna stora interna köer tillsammans med snabb service och kräver inte eller drar nytta av att ställa in en I/O-schemaläggare. Det rekommenderas att du inte har någon explicit konfigurationsparameter för schemaläggningsläge.

Du kan kontrollera din schemaläggarinställning med:

cat /sys/block/${DEVICE}/queue/scheduler

Till exempel bör det se ut så här:

cat /sys/block/sda/queue/scheduler

[noop] deadline cfq

För att göra det permanent, redigera /etc/default/grub-konfigurationsfilen, leta efter variabeln GRUB_CMDLINE_LINUX och lägg till hiss precis som nedan:

GRUB_CMDLINE_LINUX="elevator=noop"

Öka gränsen för öppna filer

För att säkerställa god serverprestanda får det totala antalet klientanslutningar, databasfiler och loggfiler inte överskrida den maximala filbeskrivningsgränsen för operativsystemet (ulimit -n). Linux-system begränsar antalet filbeskrivningar som en process kan öppna till 1 024 per process. På aktiva databasservrar (särskilt produktionsservrar) kan den lätt nå standardsystemgränsen.

För att öka detta, redigera /etc/security/limits.conf och specificera eller lägg till följande:

mysql soft nofile 65535

mysql hard nofile 65535

Detta kräver en omstart av systemet. Efteråt kan du bekräfta genom att köra följande:

$ ulimit -Sn

65535

$ ulimit -Hn

65535

Valfritt kan du ställa in detta via mysqld_safe om du startar mysqld-processen via mysqld_safe,

[mysqld_safe]

open_files_limit=4294967295

eller om du använder systemd,

sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF

[Service]



LimitNOFILE=infinity

EOF

sudo systemctl daemon-reload

Ställa in Swappiness på Linux för MariaDB

Linux Swap spelar en stor roll i databassystem. Det fungerar som ditt reservdäck i ditt fordon, när otäcka minnesläckor stör ditt arbete, kommer maskinen att sakta ner... men i de flesta fall kan den fortfarande användas för att slutföra sin tilldelade uppgift.

För att tillämpa ändringar på ditt utbyte, kör bara,

sysctl -w vm.swappiness=1

Detta sker dynamiskt, utan att behöva starta om servern. För att göra det beständigt, redigera /etc/sysctl.conf och lägg till raden,

vm.swappiness=1

Det är ganska vanligt att ställa in swappiness=0, men sedan nya kärnor släpptes (dvs kärnor> 2.6.32-303) har ändringar gjorts så att du måste ställa in vm.swappiness=1.

Filsystemoptimeringar för MariaDB

De vanligaste filsystemen som används i Linux-miljöer som kör MariaDB är ext4 och XFS. Det finns också vissa inställningar tillgängliga för att implementera en arkitektur med ZFS och BRTFS (som hänvisas till i MariaDB-dokumentationen).

Utöver detta behöver de flesta databasinställningar inte registrera filåtkomsttid. Du kanske vill inaktivera detta när du monterar volymen i systemet. För att göra detta, redigera din fil /etc/fstab. Till exempel, på en volym som heter /dev/md2, ser den ut så här:

/dev/md2 / ext4 defaults,noatime 0 0

Skapa en optimal MariaDB-instans

Lagra data på en separat volym

Det är alltid idealiskt att separera din databasdata på en separat volym. Den här volymen är specifikt för sådana typer av snabba lagringsvolymer som SSD-, NVMe- eller PCIe-kort. Till exempel, om hela din systemvolym kommer att misslyckas, kommer du att ha din databasvolym säker och vara säker på att inte påverkas om din lagringshårdvara skulle misslyckas.

Justera MariaDB för att utnyttja minnet effektivt

innodb_buffer_pool_size

Det primära värdet att justera på en databasserver med helt/primärt XtraDB/InnoDB-tabeller, kan ställas in upp till 80 % av det totala minnet i dessa miljöer. Om den är inställd på 2 GB eller mer vill du antagligen även justera innodb_buffer_pool_instances. Du kan ställa in detta dynamiskt om du använder MariaDB>=10.2.2 version. Annars kräver det en omstart av servern.

tmp_memory_table_size/max_heap_table_size

För tmp_memory_table_size (tmp_table_size), om du har att göra med stora temporära tabeller, om du ställer in detta högre ger prestandavinster eftersom det kommer att lagras i minnet. Detta är vanligt vid frågor som ofta använder GROUP BY, UNION eller underfrågor. Även om max_heap_table_size är mindre, kommer den nedre gränsen att gälla. Om en tabell överskrider gränsen konverterar MariaDB den till en MyISAM- eller Aria-tabell. Du kan se om det är nödvändigt att öka genom att jämföra statusvariablerna Created_tmp_disk_tables och Created_tmp_tables för att se hur många temporära tabeller av det totala antalet skapade som behövde konverteras till disk. Ofta är komplexa GROUP BY-frågor ansvariga för att gränsen överskrids.

Medan max_heap_table_size är det här maxstorleken för användarskapade MEMORY-tabeller. Värdet som ställs in för denna variabel är endast tillämpligt för de nyskapade eller återskapade tabellerna och inte de befintliga. Den minsta av max_heap_table_size och tmp_table_size begränsar också interna tabeller i minnet. När den maximala storleken uppnås kommer alla ytterligare försök att infoga data att få ett "tabell ... är full"-fel. Tillfälliga tabeller som skapats med CREATE TEMPORARY kommer inte att konverteras till Aria, vilket sker med interna temporära tabeller, utan kommer också att få ett tabellfel.

innodb_log_file_size

Stora minnen med höghastighetsbehandling och snabb I/O-disk är inte nytt och har sitt rimliga pris som den rekommenderar. Om du föredrar mer prestandavinster, särskilt under och hantering av dina InnoDB-transaktioner, är det rimligt att ställa in variabeln innodb_log_file_size till ett högre värde som 5Gib eller till och med 10GiB. Ökning innebär att de större transaktionerna kan köras utan att behöva utföra disk I/O innan commit.

join_buffer_size

I vissa fall tenderar dina frågor att sakna korrekt indexering eller helt enkelt finns det tillfällen som du behöver den här frågan för att köra. Inte såvida det inte kommer att bli mycket anropade eller anropade ur klientperspektivet, det är bäst att ställa in denna variabel på sessionsnivå. Öka den för att få snabbare fullständiga anslutningar när det inte är möjligt att lägga till index, men var medveten om minnesproblem, eftersom anslutningar alltid kommer att allokera minimistorleken.

Ställ in ditt max_allowed_packet

MariaDB har samma karaktär som MySQL vid hantering av paket. Den delar upp data i paket och klienten måste vara medveten om variabelvärdet max_allowed_packet. Servern kommer att ha en buffert för att lagra kroppen med en maximal storlek som motsvarar detta max_allowed_packet-värde. Om klienten skickar mer data än max_allowed_packet size kommer socket att stängas. Direktivet max_allowed_packet definierar den maximala storleken på paket som kan skickas.

Att ställa in detta värde för lågt kan göra att en fråga stoppar och stänger sin klientanslutning, vilket är ganska vanligt att ta emot fel som ER_NET_PACKET_TOO_LARGE eller Förlorad anslutning till MySQL-servern under förfrågan. Helst, speciellt på de flesta applikationskrav idag, kan du börja ställa in detta till 512MiB. Om det är en applikation med låg efterfrågan, använd bara standardvärdet och ställ in denna variabel endast via session när det behövs om data som ska skickas eller tas emot är för stort än standardvärdet (16MiB sedan MariaDB 10.2.4). I vissa arbetsbelastningar som kräver stora paket som ska bearbetas, måste du justera hans högre enligt dina behov, särskilt när du replikerar. Om max_allowed_packet är för litet på slaven gör detta också att slaven stoppar I/O-tråden.

Använda Threadpool

I vissa fall kanske denna justering inte är nödvändig eller rekommenderad för dig. Trådpooler är mest effektiva i situationer där frågorna är relativt korta och belastningen är CPU-bunden (OLTP-arbetsbelastningar). Om arbetsbelastningen inte är CPU-bunden kanske du ändå vill begränsa antalet trådar för att spara minne för databasminnesbuffertar.

Att använda threadpool är en idealisk lösning, särskilt om ditt system upplever kontextväxling och du hittar sätt att minska detta och behålla ett lägre antal trådar än antalet klienter. Detta antal bör dock inte heller vara för lågt, eftersom vi också vill utnyttja de tillgängliga CPU:erna maximalt. Därför bör det helst finnas en enda aktiv tråd för varje CPU på maskinen.

Du kan ställa in thread_pool_max_threads, thread_pool_min_threads för det maximala och minsta antalet trådar. Till skillnad från MySQL finns detta bara i MariaDB.

Ställ in variabeln thread_handling som bestämmer hur servern hanterar trådar för klientanslutningar. Förutom trådar för klientanslutningar, gäller detta även vissa interna servertrådar, som Galera-slavtrådar.

Justera din tabellcache + max_connections

Om du stöter på enstaka händelser i processlistan om status för öppningstabeller och stängningstabeller, kan det betyda att du behöver öka din tabellcache. Du kan även övervaka detta via mysql-klientprompten genom att köra VIS GLOBAL STATUS SOM 'Open%table%'; och övervaka statusvariablerna.

För max_connections, om din applikation kräver många samtidiga anslutningar, kan du börja ställa in detta till 500. 

För table_open_cache ska det vara det totala antalet tabeller men det är bäst att du lägger till fler beroende på vilken typ av frågor du betjänar eftersom temporära tabeller också ska cachelagras. Om du till exempel har 500 bord är det rimligt att du börjar med 1500. 

Medan dina table_open_cache_instances, börja ställa in den till 8. Detta kan förbättra skalbarheten genom att minska konflikter mellan sessioner, den öppna tabellcachen kan partitioneras i flera mindre cache-instanser av storleken table_open_cache / table_open_cache_instances.

För InnoDB fungerar table_definition_cache som en mjuk gräns för antalet öppna tabellinstanser i InnoDBs dataordbokscache. Värdet som ska definieras kommer att ställa in antalet tabelldefinitioner som kan lagras i definitionscachen. Om du använder ett stort antal tabeller kan du skapa en stor tabelldefinitionscache för att påskynda öppningen av tabeller. Tabelldefinitionscachen tar mindre utrymme och använder inte fildeskriptorer, till skillnad från den vanliga tabellcachen. Minimivärdet är 400. Standardvärdet är baserat på följande formel, begränsat till en gräns på 2000:

MIN(400 + table_open_cache / 2, 2000)

Om antalet öppna tabellinstanser överskrider inställningen table_definition_cache, börjar LRU-mekanismen att markera tabellinstanser för vräkning och tar så småningom bort dem från dataordbokens cache. 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. Antalet tabellinstanser med cachad metadata kan vara högre än gränsen som definieras av table_definition_cache, eftersom överordnade och underordnade tabellinstanser med främmande nyckelrelationer inte placeras på LRU-listan och inte är föremål för vräkning från minnet.

Till skillnad från table_open_cache, använder table_definition_cache inte filbeskrivningar och är mycket mindre.

Hantera frågecache

Vi rekommenderar helst att du inaktiverar frågecache i alla dina MariaDB-inställningar. Du måste se till att query_cache_type=OFF och query_cache_size=0 för att slutföra inaktivera query cache. Till skillnad från MySQL stöder MariaDB fortfarande frågecache och har inga planer på att dra tillbaka stödet för att använda frågecache. Det finns vissa personer som hävdar att frågecache fortfarande ger prestandafördelar för dem. Det här inlägget från Percona The MySQL query cache:Worst enemy or best friend avslöjar att query cache, om den är aktiverad, resulterar i en overhead och visar sig ha en dålig serverprestanda.

Om du tänker använda frågecache, se till att du övervakar din frågecache genom att köra VIS GLOBAL STATUS SOM 'Qcache%';. Qcache_inserts innehåller antalet frågor som lagts till i frågecachen, Qcache_hits innehåller antalet frågor som har använt sig av frågecachen, medan Qcache_lowmem_prunes innehåller antalet frågor som har tappats från cachen på grund av minnesbrist. Medan i sinom tid, användning och aktivering av frågecache kan bli fragmenterad. En hög Qcache_free_blocks i förhållande till Qcache_total_blocks kan indikera fragmentering. För att defragmentera den, kör FLUSH QUERY Cache. Detta kommer att defragmentera frågecachen utan att tappa några frågor.

Övervaka alltid dina servrar

Det är mycket viktigt att du övervakar dina MariaDB-noder ordentligt. Vanliga övervakningsverktyg där ute (som Nagios, Zabbix eller PMM) är tillgängliga om du tenderar att föredra gratis och öppen källkod. För företagsverktyg och fullpackade verktyg föreslår vi att du ger ClusterControl ett försök, eftersom det inte bara tillhandahåller övervakning, utan det erbjuder även prestationsrådgivare, varningar och larm som hjälper dig att förbättra din systemprestanda och hålla dig uppdaterad med den aktuella trender när du samarbetar med supportteamet. Databasövervakning med ClusterControl är gratis och en del av Community Edition.

Slutsats

Att ställa in din MariaDB-installation är nästan samma tillvägagångssätt som MySQL, men med vissa skillnader, eftersom det skiljer sig i några av dess tillvägagångssätt och versioner som det stöder. MariaDB är nu en annan enhet i databasvärlden och har snabbt fått förtroende från gemenskapen utan någon FUD. De har sina egna skäl till varför det måste implementeras på det här sättet så det är mycket viktigt att vi vet hur man ställer in detta och optimerar din(a) MariaDB-server(ar).