Lige siden MySQL oprindeligt blev brugt til at danne MariaDB, er det blevet bredt understøttet og hurtigt vedtaget af et stort publikum i open source-databasefællesskabet. Oprindeligt en drop-in erstatning, MariaDB er begyndt at skabe forskel mod MySQL, især med udgivelsen af MariaDB 10.2.
På trods af dette er der dog stadig ingen reel forskel mellem MariaDB og MySQL, da begge har motorer, der er kompatible og kan køre indbygget med hinanden. Så bliv ikke overrasket, hvis tuning af din MariaDB-opsætning har en lignende tilgang til en tuning MySQL.
Denne blog vil diskutere tuning af MariaDB, specifikt de systemer, der kører i et Linux-miljø.
MariaDB hardware- og systemoptimering
MariaDB anbefaler, at du forbedrer din hardware i følgende prioriterede rækkefølge...
Hukommelse
Hukommelse er den vigtigste faktor for databaser, da den giver dig mulighed for at justere serverens systemvariabler. Mere hukommelse betyder større nøgle- og tabelcaches, som er gemt i hukommelsen, så diske kan få adgang, en størrelsesorden langsommere, reduceres efterfølgende.
Husk dog, blot tilføjelse af mere hukommelse vil muligvis ikke resultere i drastiske forbedringer, hvis servervariablerne ikke er indstillet til at gøre brug af den ekstra tilgængelige hukommelse.
Brug af flere RAM-slots på bundkortet øger busfrekvensen, og der vil være mere latenstid mellem RAM'en og CPU'en. Det betyder, at det er at foretrække at bruge den højeste RAM-størrelse pr. slot.
Diske
Hurtig diskadgang er kritisk, da det i sidste ende er der, hvor dataene ligger. Nøgletallet er disksøgningstiden (et mål for hvor hurtigt den fysiske disk kan bevæge sig for at få adgang til dataene), så vælg diske med så lav søgetid som muligt. Du kan også tilføje dedikerede diske til midlertidige filer og transaktionslogfiler.
Hurtigt Ethernet
Med de passende krav til din internetbåndbredde betyder hurtigt ethernet, at det kan have hurtigere respons på klienters anmodninger, replikeringssvartid til at læse binære logfiler på tværs af slaverne, hurtigere responstider er også meget vigtigt, især på Galera -baserede klynger.
CPU
Selvom hardwareflaskehalse ofte falder andre steder, gør hurtigere processorer det muligt at udføre beregninger hurtigere, og resultaterne sendes tilbage til klienten hurtigere. Udover processorhastighed er processorens bushastighed og cachestørrelse også vigtige faktorer at overveje.
Indstilling af din disk I/O-planlægning
I/O-planlæggere findes som en måde at optimere anmodninger om diskadgang. Den fletter I/O-anmodninger til lignende placeringer på disken. Dette betyder, at diskdrevet ikke behøver at søge så ofte og forbedrer en enorm samlet responstid og sparer diskoperationer. De anbefalede værdier for I/O-ydelse er noop og deadline.
noop er nyttigt til at kontrollere, om komplekse I/O-planlægningsbeslutninger fra andre planlæggere ikke forårsager I/O-ydeevneregressioner. I nogle tilfælde kan det være nyttigt for enheder, der selv laver I/O-planlægning, som intelligent lagring, eller enheder, der ikke er afhængige af mekanisk bevægelse, såsom SSD'er. Normalt er DEADLINE I/O-planlæggeren et bedre valg til disse enheder, men på grund af mindre overhead kan NOOP give bedre ydeevne på visse arbejdsbelastninger.
For deadline er det en latensorienteret I/O-planlægger. Hver I/O-anmodning har fået tildelt en deadline. Normalt lagres anmodninger i køer (læse og skrive) sorteret efter sektornumre. DEADLINE-algoritmen vedligeholder to ekstra køer (læse og skrive), hvor anmodningerne er sorteret efter deadline. Så længe ingen anmodning har timeout, bruges "sektor"-køen. Hvis der opstår timeouts, serveres anmodninger fra "deadline"-køen, indtil der ikke er flere udløbne anmodninger. Generelt foretrækker algoritmen læsning frem for skrivning.
For PCIe-enheder (NVMe SSD-drev) har de deres egne store interne køer sammen med hurtig service og kræver eller har ikke gavn af at indstille en I/O-planlægger. Det anbefales ikke at have nogen eksplicit konfigurationsparameter for planlægningstilstand.
Du kan tjekke din planlægningsindstilling med:
cat /sys/block/${DEVICE}/queue/schedulerFor eksempel skulle det se ud som dette output:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqFor at gøre det permanent, rediger /etc/default/grub-konfigurationsfilen, se efter variablen GRUB_CMDLINE_LINUX og tilføj elevator ligesom nedenfor:
GRUB_CMDLINE_LINUX="elevator=noop"Forøg grænsen for åbne filer
For at sikre god serverydeevne må det samlede antal klientforbindelser, databasefiler og logfiler ikke overstige den maksimale filbeskrivelsesgrænse på operativsystemet (ulimit -n). Linux-systemer begrænser antallet af filbeskrivelser, som enhver proces kan åbne til 1.024 pr. proces. På aktive databaseservere (især produktionsservere) kan den nemt nå standard systemgrænsen.
For at øge dette skal du redigere /etc/security/limits.conf og angive eller tilføje følgende:
mysql soft nofile 65535
mysql hard nofile 65535Dette kræver en systemgenstart. Bagefter kan du bekræfte ved at køre følgende:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Du kan valgfrit indstille dette via mysqld_safe, hvis du starter mysqld-processen gennem mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295eller hvis du bruger systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadIndstilling af Swappiness på Linux til MariaDB
Linux Swap spiller en stor rolle i databasesystemer. Det fungerer som dit reservehjul i dit køretøj, når grimme hukommelseslækager forstyrrer dit arbejde, vil maskinen sænke farten... men i de fleste tilfælde vil den stadig være brugbar til at afslutte den tildelte opgave.
For at anvende ændringer til din swappiness skal du blot køre,
sysctl -w vm.swappiness=1Dette sker dynamisk uden behov for at genstarte serveren. For at gøre det vedvarende skal du redigere /etc/sysctl.conf og tilføje linjen,
vm.swappiness=1Det er ret almindeligt at sætte swappiness=0, men siden udgivelsen af nye kerner (dvs. kerner> 2.6.32-303), er der foretaget ændringer, så du skal indstille vm.swappiness=1.
Filsystemoptimeringer til MariaDB
De mest almindelige filsystemer, der bruges i Linux-miljøer, der kører MariaDB, er ext4 og XFS. Der er også visse opsætninger tilgængelige til implementering af en arkitektur ved hjælp af ZFS og BRTFS (som refereret i MariaDB-dokumentationen).
Ud over dette behøver de fleste databaseopsætninger ikke at registrere filadgangstid. Du ønsker måske at deaktivere dette, når du monterer lydstyrken i systemet. For at gøre dette, rediger din fil /etc/fstab. For eksempel, på en diskenhed ved navn /dev/md2, ser det sådan ud:
/dev/md2 / ext4 defaults,noatime 0 0Oprettelse af en optimal MariaDB-instans
Gem data på et separat volumen
Det er altid ideelt at adskille dine databasedata på et separat volumen. Denne diskenhed er specifikt til de typer hurtige lagervolumener såsom SSD-, NVMe- eller PCIe-kort. For eksempel, hvis hele din systemvolumen vil svigte, vil du have din databasevolumen sikker og være sikker på ikke at blive påvirket i tilfælde af, at din lagringshardware fejler.
Juster MariaDB for at udnytte hukommelsen effektivt
innodb_buffer_pool_size
Den primære værdi, der skal justeres på en databaseserver med udelukkende/primært XtraDB/InnoDB-tabeller, kan sættes op til 80 % af den samlede hukommelse i disse miljøer. Hvis indstillet til 2 GB eller mere, vil du sandsynligvis også justere innodb_buffer_pool_instances. Du kan indstille dette dynamisk, hvis du bruger MariaDB>=10.2.2 version. Ellers kræver det en servergenstart.
tmp_memory_table_size/max_heap_table_size
For tmp_memory_table_size (tmp_table_size), hvis du har at gøre med store midlertidige tabeller, giver indstilling af denne højere ydeevneforbedringer, da det vil blive lagret i hukommelsen. Dette er almindeligt på forespørgsler, der i høj grad bruger GROUP BY, UNION eller underforespørgsler. Selvom max_heap_table_size er mindre, gælder den nedre grænse. Hvis en tabel overskrider grænsen, konverterer MariaDB den til en MyISAM- eller Aria-tabel. Du kan se, om det er nødvendigt at øge, ved at sammenligne statusvariablerne Created_tmp_disk_tables og Created_tmp_tables for at se, hvor mange midlertidige tabeller ud af det samlede oprettede antal der skulle konverteres til disk. Ofte er komplekse GROUP BY-forespørgsler ansvarlige for at overskride grænsen.
Mens max_heap_table_size, er dette den maksimale størrelse for brugeroprettede MEMORY-tabeller. Værdien indstillet på denne variabel gælder kun for de nyoprettede eller genskabte tabeller og ikke de eksisterende. Den mindste af max_heap_table_size og tmp_table_size begrænser også interne tabeller i hukommelsen. Når den maksimale størrelse er nået, vil ethvert yderligere forsøg på at indsætte data modtage en "tabel ... er fuld" fejl. Midlertidige tabeller oprettet med CREATE TEMPORARY vil ikke blive konverteret til Aria, som det sker med interne midlertidige tabeller, men vil også modtage en tabel fuld fejl.
innodb_log_file_size
Store hukommelser med højhastighedsbehandling og hurtig I/O-disk er ikke nye og har sin rimelige pris, som den anbefaler. Hvis du foretrækker flere præstationsgevinster, især under og håndtering af dine InnoDB-transaktioner, er det rimeligt at indstille variablen innodb_log_file_size til en større værdi såsom 5Gib eller endda 10GiB. Stigende betyder, at de større transaktioner kan køre uden at skulle udføre disk I/O før commit.
join_buffer_size
I nogle tilfælde har dine forespørgsler en tendens til at mangle brug af korrekt indeksering eller simpelthen er der tilfælde, hvor du har brug for denne forespørgsel for at køre. Ikke medmindre det bliver stærkt kaldt eller påkaldt fra klientperspektivet, er indstilling af denne variabel bedst på sessionsniveau. Forøg den for at få hurtigere fulde joinforbindelser, når tilføjelse af indekser ikke er muligt, men vær opmærksom på hukommelsesproblemer, da joins altid vil tildele minimumsstørrelsen.
Indstil din max_allowed_packet
MariaDB har samme karakter som MySQL ved håndtering af pakker. Den opdeler data i pakker, og klienten skal være opmærksom på max_allowed_packet variabelværdien. Serveren vil have en buffer til at gemme kroppen med en maksimal størrelse svarende til denne max_allowed_packet værdi. Hvis klienten sender flere data end max_allowed_packet size, lukkes socket. Direktivet max_allowed_packet definerer den maksimale størrelse på pakken, der kan sendes.
Indstilling af denne værdi for lavt kan få en forespørgsel til at stoppe og lukke sin klientforbindelse, hvilket er ret almindeligt at modtage fejl som ER_NET_PACKET_TOO_LARGE eller Mistet forbindelse til MySQL-serveren under forespørgsel. Ideelt set, især på de fleste applikationskrav i dag, kan du begynde at indstille dette til 512MiB. Hvis det er en applikationstype med lav efterspørgsel, skal du blot bruge standardværdien og kun indstille denne variabel via session, når det er nødvendigt, hvis dataene, der skal sendes eller modtages, er for store end standardværdien (16MiB siden MariaDB 10.2.4). I visse arbejdsbelastninger, der kræver store pakker, der skal behandles, skal du justere hans højere efter dine behov, især når du er på replikering. Hvis max_allowed_packet er for lille på slaven, får dette også slaven til at stoppe I/O-tråden.
Brug af Threadpool
I nogle tilfælde er denne indstilling muligvis ikke nødvendig eller anbefalet til dig. Threadpools er mest effektive i situationer, hvor forespørgsler er relativt korte, og belastningen er CPU-bundet (OLTP-arbejdsbelastninger). Hvis arbejdsbyrden ikke er CPU-bundet, vil du måske stadig begrænse antallet af tråde for at spare hukommelse til databasehukommelsesbufferne.
Brug af threadpool er en ideel løsning, især hvis dit system oplever kontekstskifte, og du finder måder at reducere dette og opretholde et lavere antal tråde end antallet af klienter. Dette tal bør dog heller ikke være for lavt, da vi også ønsker at udnytte de tilgængelige CPU'er maksimalt. Derfor bør der ideelt set være en enkelt aktiv tråd for hver CPU på maskinen.
Du kan indstille thread_pool_max_threads, thread_pool_min_threads for maksimum og minimum antal tråde. I modsætning til MySQL er dette kun til stede i MariaDB.
Indstil variablen thread_handling, som bestemmer, hvordan serveren håndterer tråde til klientforbindelser. Ud over tråde til klientforbindelser gælder dette også for visse interne servertråde, såsom Galera-slavetråde.
Juster din tabelcache + max_connections
Hvis du står over for lejlighedsvise hændelser i proceslisten om statusser for åbning af tabeller og lukning af tabeller, kan det betyde, at du skal øge din tabelcache. Du kan også overvåge dette via mysql-klientprompten ved at køre VIS GLOBAL STATUS SOM 'Open%table%'; og overvåge statusvariablerne.
For max_connections, hvis din applikation kræver mange samtidige forbindelser, kan du begynde at indstille dette til 500.
For table_open_cache skal det være det samlede antal af dine tabeller, men det er bedst, du tilføjer flere afhængigt af typen af forespørgsler, du tjener, da midlertidige tabeller også skal cachelagres. For eksempel, hvis du har 500 borde, ville det være rimeligt, at du starter med 1500.
Mens dine table_open_cache_instances, start med at indstille den til 8. Dette kan forbedre skalerbarheden ved at reducere stridigheder mellem sessioner, åbne tabellers cache kan opdeles i flere mindre cache-forekomster af størrelse table_open_cache / table_open_cache_instances.
For InnoDB fungerer table_definition_cache som en blød grænse for antallet af åbne tabelforekomster i InnoDBs dataordbogs cache. Den værdi, der skal defineres, vil indstille antallet af tabeldefinitioner, der kan gemmes i definitionscachen. Hvis du bruger et stort antal tabeller, kan du oprette en stor tabeldefinitionscache for at fremskynde åbningen af tabeller. Tabeldefinitionscachen tager mindre plads og bruger ikke filbeskrivelser, i modsætning til den normale tabelcache. Minimumsværdien er 400. Standardværdien er baseret på følgende formel, begrænset til en grænse på 2000:
MIN(400 + table_open_cache / 2, 2000)Hvis antallet af åbne tabelforekomster overstiger table_definition_cache-indstillingen, begynder LRU-mekanismen at markere tabelforekomster til udsættelse og fjerner dem til sidst fra dataordbogens cache. Grænsen hjælper med at løse situationer, hvor betydelige mængder hukommelse ville blive brugt til at cache sjældent brugte tabelforekomster, indtil den næste servergenstart. Antallet af tabelforekomster med cachelagrede metadata kan være højere end grænsen defineret af table_definition_cache, fordi overordnede og underordnede tabelforekomster med fremmednøglerelationer ikke placeres på LRU-listen og ikke er genstand for udelukkelse fra hukommelsen.
I modsætning til table_open_cachen bruger table_definition_cachen ikke filbeskrivelser og er meget mindre.
Håndtering af forespørgselscache
Vi anbefaler helst at deaktivere forespørgselscache i hele din MariaDB-opsætning. Du skal sikre, at query_cache_type=OFF og query_cache_size=0 for at fuldføre deaktivering af forespørgselscache. I modsætning til MySQL understøtter MariaDB stadig forespørgselscache og har ingen planer om at trække sin støtte tilbage til at bruge forespørgselscache. Der er nogle mennesker, der hævder, at forespørgselscache stadig giver ydeevnefordele for dem. Men dette indlæg fra Percona MySQL-forespørgselscachen:Værste fjende eller bedste ven afslører, at forespørgselscache, hvis den er aktiveret, resulterer i en overhead og viser sig at have en dårlig serverydelse.
Hvis du har til hensigt at bruge forespørgselscache, skal du sørge for at overvåge din forespørgselscache ved at køre VIS GLOBAL STATUS SOM 'Qcache%';. Qcache_inserts indeholder antallet af forespørgsler tilføjet til forespørgselscachen, Qcache_hits indeholder antallet af forespørgsler, der har gjort brug af forespørgselscachen, mens Qcache_lowmem_prunes indeholder antallet af forespørgsler, der blev slettet fra cachen på grund af manglende hukommelse. Mens der er rettidigt, kan brug og aktivering af forespørgselscache blive fragmenteret. En høj Qcache_free_blocks i forhold til Qcache_total_blocks kan indikere fragmentering. For at defragmentere den skal du køre FLUSH QUERY CACHE. Dette vil defragmentere forespørgselscachen uden at slippe nogen forespørgsler.
Overvåg altid dine servere
Det er meget vigtigt, at du overvåger dine MariaDB-noder korrekt. Almindelige overvågningsværktøjer derude (såsom Nagios, Zabbix eller PMM) er tilgængelige, hvis du har tendens til at foretrække gratis og open source-værktøjer. For virksomheder og fuldt pakkede værktøjer foreslår vi, at du giver ClusterControl en chance, da den ikke kun giver overvågning, men den tilbyder også præstationsrådgivere, advarsler og alarmer, som hjælper dig med at forbedre dit systems ydeevne og holde dig ajour med den aktuelle tendenser, mens du interagerer med supportteamet. Databaseovervågning med ClusterControl er gratis og en del af Community Edition.
Konklusion
Tuning af din MariaDB-opsætning er næsten den samme tilgang som MySQL, men med nogle forskelle, da den adskiller sig i nogle af dens tilgange og versioner, som den understøtter. MariaDB er nu en anden enhed i databaseverdenen og har hurtigt fået tillid fra fællesskabet uden nogen FUD. De har deres egne grunde til, hvorfor det skal implementeres på denne måde, så det er meget vigtigt, at vi ved, hvordan vi tuner dette og optimerer din(e) MariaDB-server(e).