Sinds MySQL oorspronkelijk werd gevorkt om MariaDB te vormen, wordt het breed ondersteund en snel overgenomen door een groot publiek in de open source database-gemeenschap. Oorspronkelijk een drop-in vervanging, is MariaDB begonnen onderscheid te maken met MySQL, vooral met de release van MariaDB 10.2.
Ondanks dit is er nog steeds geen echt veelbetekenend verschil tussen MariaDB en MySQL, aangezien beide engines hebben die compatibel zijn en native met elkaar kunnen werken. Wees dus niet verbaasd als het afstemmen van uw MariaDB-configuratie een vergelijkbare benadering heeft als het afstemmen van MySQL.
In deze blog wordt de afstemming van MariaDB besproken, met name die systemen die in een Linux-omgeving draaien.
MariaDB hardware- en systeemoptimalisatie
MariaDB raadt u aan uw hardware in de volgende prioriteitsvolgorde te verbeteren...
Geheugen
Geheugen is de belangrijkste factor voor databases, omdat je hiermee de serversysteemvariabelen kunt aanpassen. Meer geheugen betekent grotere sleutel- en tabelcaches, die in het geheugen worden opgeslagen zodat schijven toegang hebben, een orde van grootte langzamer, en vervolgens worden verminderd.
Houd er echter rekening mee dat het toevoegen van meer geheugen niet kan leiden tot drastische verbeteringen als de servervariabelen niet zijn ingesteld om gebruik te maken van het extra beschikbare geheugen.
Het gebruik van meer RAM-slots op het moederbord verhoogt de busfrequentie en er zal meer latentie zijn tussen het RAM-geheugen en de CPU. Dit betekent dat het gebruik van de hoogste RAM-grootte per slot de voorkeur heeft.
Schijven
Snelle schijftoegang is van cruciaal belang, omdat het uiteindelijk de locatie is waar de gegevens zich bevinden. Het belangrijkste cijfer is de zoektijd van de schijf (een maat voor hoe snel de fysieke schijf kan bewegen om toegang te krijgen tot de gegevens), dus kies schijven met een zo laag mogelijke zoektijd. U kunt ook speciale schijven toevoegen voor tijdelijke bestanden en transactielogboeken.
Fast Ethernet
Met de juiste vereisten voor uw internetbandbreedte, betekent snel ethernet dat het sneller kan reageren op verzoeken van klanten, replicatiereactietijd om binaire logs over de slaven te lezen, snellere reactietijden zijn ook erg belangrijk, vooral op Galera gebaseerde clusters.
CPU
Hoewel hardwareknelpunten vaak ergens anders liggen, zorgen snellere processors ervoor dat berekeningen sneller worden uitgevoerd en dat de resultaten sneller naar de client worden teruggestuurd. Naast de processorsnelheid zijn ook de bussnelheid en de cachegrootte van de processor belangrijke factoren om te overwegen.
Uw schijf-I/O-planner instellen
I/O-planners bestaan als een manier om schijftoegangsverzoeken te optimaliseren. Het voegt I/O-verzoeken samen met vergelijkbare locaties op de schijf. Dit betekent dat de schijf niet zo vaak hoeft te zoeken en verbetert een enorme algehele responstijd en bespaart schijfbewerkingen. De aanbevolen waarden voor I/O-prestaties zijn noop en deadline.
noop is handig om te controleren of complexe I/O-planningsbeslissingen van andere planners geen I/O-prestatieregressie veroorzaken. In sommige gevallen kan het handig zijn voor apparaten die zelf I/O-planning uitvoeren, als intelligente opslag, of apparaten die niet afhankelijk zijn van mechanische bewegingen, zoals SSD's. Gewoonlijk is de DEADLINE I/O-planner een betere keuze voor deze apparaten, maar door minder overhead kan NOOP betere prestaties leveren bij bepaalde werkbelastingen.
Voor deadlines is het een latency-georiënteerde I/O-planner. Aan elk I/O-verzoek is een deadline toegewezen. Gewoonlijk worden verzoeken opgeslagen in wachtrijen (lezen en schrijven) gesorteerd op sectornummers. Het DEADLINE-algoritme houdt twee extra wachtrijen bij (lezen en schrijven) waar de verzoeken worden gesorteerd op deadline. Zolang er geen verzoek is verlopen, wordt de wachtrij "sector" gebruikt. Als er time-outs optreden, worden verzoeken uit de wachtrij "deadline" geserveerd totdat er geen verlopen verzoeken meer zijn. Over het algemeen geeft het algoritme de voorkeur aan lezen boven schrijven.
Voor PCIe-apparaten (NVMe SSD-schijven) hebben ze hun eigen grote interne wachtrijen samen met snelle service en hebben ze geen I/O-planner nodig of hebben ze er baat bij. Het wordt aanbevolen om geen expliciete configuratieparameter in de planner-modus te hebben.
U kunt uw planner-instelling controleren met:
cat /sys/block/${DEVICE}/queue/schedulerHet zou er bijvoorbeeld als volgt uit moeten zien:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqOm het permanent te maken, bewerk je het /etc/default/grub configuratiebestand, zoek je naar de variabele GRUB_CMDLINE_LINUX en voeg je de lift toe zoals hieronder:
GRUB_CMDLINE_LINUX="elevator=noop"Verhoog de limiet voor het openen van bestanden
Om goede serverprestaties te garanderen, mag het totale aantal clientverbindingen, databasebestanden en logbestanden de maximale bestandsdescriptorlimiet van het besturingssysteem (ulimit -n) niet overschrijden. Linux-systemen beperken het aantal bestandsdescriptors dat een proces kan openen tot 1024 per proces. Op actieve databaseservers (vooral productieservers) kan het gemakkelijk de standaard systeemlimiet bereiken.
Om dit te vergroten, bewerkt u /etc/security/limits.conf en specificeert of voegt u het volgende toe:
mysql soft nofile 65535
mysql hard nofile 65535Dit vereist een herstart van het systeem. Daarna kunt u bevestigen door het volgende uit te voeren:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Optioneel kun je dit instellen via mysqld_safe als je het mysqld-proces start via mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295of als je systemd gebruikt,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadSwappiness instellen op Linux voor MariaDB
Linux Swap speelt een grote rol in databasesystemen. Het werkt als uw reservewiel in uw voertuig, wanneer vervelende geheugenlekken uw werk verstoren, zal de machine vertragen... maar in de meeste gevallen nog steeds bruikbaar zijn om de toegewezen taak te voltooien.
Om wijzigingen aan uw swappiness toe te passen, voert u gewoon uit,
sysctl -w vm.swappiness=1Dit gebeurt dynamisch, zonder dat de server opnieuw hoeft te worden opgestart. Om het persistent te maken, bewerkt u /etc/sysctl.conf en voegt u de regel toe,
vm.swappiness=1Het is vrij gebruikelijk om swappiness=0 in te stellen, maar sinds de release van nieuwe kernels (d.w.z. kernels> 2.6.32-303) zijn er wijzigingen aangebracht, dus u moet vm.swappiness=1 instellen.
Bestandssysteemoptimalisaties voor MariaDB
De meest gebruikte bestandssystemen in Linux-omgevingen met MariaDB zijn ext4 en XFS. Er zijn ook bepaalde instellingen beschikbaar voor het implementeren van een architectuur met ZFS en BRTFS (zoals vermeld in de MariaDB-documentatie).
Bovendien hoeven de meeste database-instellingen de toegangstijd voor bestanden niet vast te leggen. Misschien wilt u dit uitschakelen wanneer u het volume in het systeem koppelt. Om dit te doen, bewerkt u uw bestand /etc/fstab. Op een volume met de naam /dev/md2 ziet het er bijvoorbeeld zo uit:
/dev/md2 / ext4 defaults,noatime 0 0Een optimale MariaDB-instantie maken
Gegevens opslaan op een apart volume
Het is altijd ideaal om uw databasegegevens op een apart volume te scheiden. Dit volume is specifiek voor dat soort snelle opslagvolumes zoals SSD-, NVMe- of PCIe-kaarten. Als uw volledige systeemvolume bijvoorbeeld uitvalt, bent u verzekerd van een veilig databasevolume en kunt u er zeker van zijn dat dit niet wordt aangetast in het geval dat uw opslaghardware uitvalt.
MariaDB afstemmen om het geheugen efficiënt te gebruiken
innodb_buffer_pool_size
De primaire waarde die moet worden aangepast op een databaseserver met geheel/voornamelijk XtraDB/InnoDB-tabellen, kan in deze omgevingen worden ingesteld tot 80% van het totale geheugen. Indien ingesteld op 2 GB of meer, wil je waarschijnlijk ook innodb_buffer_pool_instances aanpassen. U kunt dit dynamisch instellen als u MariaDB>=10.2.2-versie gebruikt. Anders moet de server opnieuw worden opgestart.
tmp_memory_table_size/max_heap_table_size
Voor tmp_memory_table_size (tmp_table_size), als je te maken hebt met grote tijdelijke tabellen, biedt het hoger instellen van dit hogere prestatieverbeteringen omdat het in het geheugen wordt opgeslagen. Dit is gebruikelijk bij query's die veel gebruikmaken van GROUP BY, UNION of subquery's. Hoewel als max_heap_table_size kleiner is, de ondergrens van toepassing is. Als een tabel de limiet overschrijdt, converteert MariaDB deze naar een MyISAM- of Aria-tabel. U kunt zien of het nodig is om te verhogen door de statusvariabelen Created_tmp_disk_tables en Created_tmp_tables te vergelijken om te zien hoeveel tijdelijke tabellen van het totaal gecreëerde nodig waren om naar schijf te worden geconverteerd. Vaak zijn complexe GROUP BY-query's verantwoordelijk voor het overschrijden van de limiet.
Hoewel max_heap_table_size, is dit de maximale grootte voor door gebruikers gemaakte MEMORY-tabellen. De waarde die voor deze variabele is ingesteld, is alleen van toepassing op de nieuw gemaakte of opnieuw gemaakte tabellen en niet op de bestaande. De kleinste van max_heap_table_size en tmp_table_size beperkt ook interne tabellen in het geheugen. Wanneer de maximale grootte is bereikt, wordt bij alle verdere pogingen om gegevens in te voegen de foutmelding "tabel ... is vol" weergegeven. Tijdelijke tabellen die zijn gemaakt met CREATE TEMPORARY worden niet geconverteerd naar Aria, zoals bij interne tijdelijke tabellen wel het geval is, maar krijgen ook een tabel met een volledige foutmelding.
innodb_log_file_size
Grote geheugens met snelle verwerking en snelle I/O-schijf zijn niet nieuw en hebben een redelijke prijs, zoals het aanbeveelt. Als u de voorkeur geeft aan meer prestatiewinst, vooral tijdens en het afhandelen van uw InnoDB-transacties, is het redelijk om de variabele innodb_log_file_size in te stellen op een grotere waarde, zoals 5Gib of zelfs 10GiB. Verhogen betekent dat de grotere transacties kunnen worden uitgevoerd zonder dat schijf-I/O moet worden uitgevoerd voordat ze worden vastgelegd.
join_buffer_size
In sommige gevallen hebben uw zoekopdrachten de neiging om het gebruik van de juiste indexering niet te gebruiken, of er zijn gevallen waarin u deze zoekopdracht nodig heeft om uit te voeren. Tenzij het vanuit het perspectief van de klant zwaar wordt aangeroepen of aangeroepen, is het instellen van deze variabele het beste op sessieniveau. Verhoog het om snellere volledige joins te krijgen wanneer het toevoegen van indexen niet mogelijk is, maar houd rekening met geheugenproblemen, aangezien joins altijd de minimale grootte toewijzen.
Stel uw max_allowed_packet in
MariaDB heeft dezelfde aard als MySQL bij het verwerken van pakketten. Het splitst gegevens in pakketten en de client moet zich bewust zijn van de max_allowed_packet variabele waarde. De server heeft een buffer om de body op te slaan met een maximale grootte die overeenkomt met deze max_allowed_packet-waarde. Als de client meer gegevens verzendt dan max_allowed_packet size, wordt de socket gesloten. De max_allowed_packet-richtlijn definieert de maximale grootte van het pakket dat kan worden verzonden.
Als u deze waarde te laag instelt, kan een query stoppen en de clientverbinding sluiten, wat vrij gebruikelijk is om fouten te ontvangen zoals ER_NET_PACKET_TOO_LARGE of Verbinding met MySQL-server verbroken tijdens query. Idealiter, vooral bij de meeste applicatie-eisen van tegenwoordig, kunt u dit instellen op 512 MiB. Als het een applicatie met weinig vraag is, gebruik dan gewoon de standaardwaarde en stel deze variabele alleen in via sessie wanneer dat nodig is als de te verzenden of ontvangen gegevens te groot zijn dan de standaardwaarde (16 MiB sinds MariaDB 10.2.4). In bepaalde workloads die grote pakketten vereisen om te worden verwerkt, moet u zijn hogere aanpassen aan uw behoeften, vooral bij replicatie. Als max_allowed_packet op de slave te klein is, zorgt dit er ook voor dat de slave de I/O-thread stopt.
Threadpool gebruiken
In sommige gevallen is deze afstemming misschien niet nodig of aanbevolen voor jou. Threadpools zijn het meest efficiënt in situaties waarin query's relatief kort zijn en de belasting CPU-gebonden is (OLTP-workloads). Als de werkbelasting niet CPU-gebonden is, wilt u misschien toch het aantal threads beperken om geheugen voor de databasegeheugenbuffers te besparen.
Het gebruik van threadpool is een ideale oplossing, vooral als uw systeem contextwisselingen ervaart en u manieren vindt om dit te verminderen en een lager aantal threads te behouden dan het aantal clients. Dit aantal moet echter ook niet te laag zijn, aangezien we ook maximaal gebruik willen maken van de beschikbare CPU's. Daarom zou er idealiter één enkele actieve thread moeten zijn voor elke CPU op de machine.
Je kunt thread_pool_max_threads, thread_pool_min_threads instellen voor het maximum en het minimum aantal threads. In tegenstelling tot MySQL is dit alleen aanwezig in MariaDB.
Stel de variabele thread_handling in die bepaalt hoe de server omgaat met threads voor clientverbindingen. Naast threads voor clientverbindingen geldt dit ook voor bepaalde interne serverthreads, zoals Galera-slavethreads.
Tune uw tabelcache + max_connections
Als u af en toe te maken krijgt met gebeurtenissen in de proceslijst over het openen van tabellen en het sluiten van tabellen, kan dit betekenen dat u uw tabelcache moet vergroten. U kunt dit ook controleren via de mysql-clientprompt door SHOW GLOBAL STATUS LIKE 'Open%table%' uit te voeren; en controleer de statusvariabelen.
Voor max_connections, als uw applicatie veel gelijktijdige verbindingen vereist, kunt u dit instellen op 500.
Voor table_open_cache is dit het totale aantal tabellen, maar u kunt er het beste meer aan toevoegen, afhankelijk van het type query's dat u uitvoert, aangezien tijdelijke tabellen ook in de cache worden opgeslagen. Als u bijvoorbeeld 500 tafels heeft, zou het redelijk zijn om met 1500 te beginnen.
Terwijl je table_open_cache_instances deze instelt op 8. Dit kan de schaalbaarheid verbeteren door de strijd tussen sessies te verminderen. De cache met open tabellen kan worden gepartitioneerd in verschillende kleinere cache-instanties van de grootte table_open_cache / table_open_cache_instances.
Voor InnoDB fungeert table_definition_cache als een zachte limiet voor het aantal open tabelinstanties in de cache van de InnoDB datadictionary. De te definiëren waarde bepaalt het aantal tabeldefinities dat kan worden opgeslagen in de definitiecache. Als u een groot aantal tabellen gebruikt, kunt u een grote tabeldefinitiecache maken om het openen van tabellen te versnellen. De tabeldefinitiecache neemt minder ruimte in beslag en gebruikt geen bestandsdescriptors, in tegenstelling tot de normale tabelcache. De minimumwaarde is 400. De standaardwaarde is gebaseerd op de volgende formule, met een maximum van 2000:
MIN(400 + table_open_cache / 2, 2000)Als het aantal geopende tabelinstanties de instelling table_definition_cache overschrijdt, begint het LRU-mechanisme tabelinstanties te markeren voor verwijdering en verwijdert deze uiteindelijk uit de datadictionary-cache. De limiet helpt situaties aan te pakken waarin aanzienlijke hoeveelheden geheugen zouden worden gebruikt voor het cachen van zelden gebruikte tabelinstanties tot de volgende herstart van de server. Het aantal tabelinstanties met metagegevens in de cache kan hoger zijn dan de limiet die is gedefinieerd door table_definition_cache, omdat instanties van bovenliggende en onderliggende tabellen met externe-sleutelrelaties niet op de LRU-lijst worden geplaatst en niet uit het geheugen kunnen worden verwijderd.
In tegenstelling tot de table_open_cache, gebruikt de table_definition_cache geen bestandsdescriptors en is deze veel kleiner.
Omgaan met querycache
Bij voorkeur raden we aan om de querycache in al je MariaDB-instellingen uit te schakelen. U moet ervoor zorgen dat query_cache_type=OFF en query_cache_size=0 om de querycache volledig uit te schakelen. In tegenstelling tot MySQL ondersteunt MariaDB de querycache nog steeds volledig en heeft ze geen plannen om de ondersteuning voor het gebruik van querycache in te trekken. Er zijn mensen die beweren dat de querycache nog steeds prestatievoordelen voor hen biedt. Echter, dit bericht van Percona De MySQL-querycache:Slechtste vijand of beste vriend onthult dat querycache, indien ingeschakeld, leidt tot overhead en slechte serverprestaties vertoont.
Als u querycache wilt gebruiken, zorg er dan voor dat u uw querycache controleert door SHOW GLOBAL STATUS LIKE 'Qcache%'; uit te voeren. Qcache_inserts bevat het aantal query's dat aan de querycache is toegevoegd, Qcache_hits bevat het aantal query's dat gebruik heeft gemaakt van de querycache, terwijl Qcache_lowmem_prunes het aantal query's bevat dat uit de cache is verwijderd vanwege gebrek aan geheugen. Na verloop van tijd kan het gebruik en inschakelen van querycache gefragmenteerd raken. Een hoge Qcache_free_blocks ten opzichte van Qcache_total_blocks kan duiden op fragmentatie. Om het te defragmenteren, voert u FLUSH QUERY CACHE uit. Dit zal de querycache defragmenteren zonder query's te laten vallen.
Bewaak altijd uw servers
Het is zeer belangrijk dat u uw MariaDB-knooppunten goed bewaakt. Gemeenschappelijke monitoringtools die er zijn (zoals Nagios, Zabbix of PMM) zijn beschikbaar als je de voorkeur geeft aan gratis en open-source tools. Voor zakelijke en volledig verpakte tools raden we u aan ClusterControl eens te proberen, omdat het niet alleen monitoring biedt, maar ook prestatieadviseurs, waarschuwingen en alarmen biedt die u helpen uw systeemprestaties te verbeteren en up-to-date te blijven met de huidige trends terwijl u samenwerkt met het ondersteuningsteam. Databasemonitoring met ClusterControl is gratis en maakt deel uit van de Community-editie.
Conclusie
Het afstemmen van uw MariaDB-configuratie is bijna dezelfde benadering als MySQL, maar met enkele verschillen, omdat het verschilt in sommige benaderingen en versies die het ondersteunt. MariaDB is nu een andere entiteit in de databasewereld en heeft snel het vertrouwen van de gemeenschap gewonnen zonder enige FUD. Ze hebben hun eigen redenen waarom het op deze manier moet worden geïmplementeerd, dus het is erg belangrijk dat we weten hoe we dit kunnen afstemmen en uw MariaDB-server(s) kunnen optimaliseren.