NVMe-tuning op Linux-servers: een complete optimalisatiehandleiding

Als je met Linux-servers werkt en bent overgestapt op NVMe-schijven, heb je waarschijnlijk gemerkt dat, hoewel ze veel sneller dan harde schijven of zelfs SSD SATADe spectaculaire cijfers die in de specificaties worden beloofd, zie je niet altijd terug in de praktijk. Het ligt niet aan de hardware: meestal zijn het het besturingssysteem, de kernelconfiguratie en de services die de prestaties beperken.

In dit artikel gaan we bekijken hoe je een bepaalde actie uitvoert. Serieuze NVMe-optimalisatie op Linux-serversWe kijken zowel naar pure prestaties (latentie, IOPS en bandbreedte) als naar de duurzaamheid van de schijf. Bovendien integreren we het met de databaselaag (MySQL/MariaDB, met name InnoDB) en met best practices voor het gebruik van SSD's en NVMe om ervoor te zorgen dat uw platform optimaal presteert. Het doel is dat u naadloos kunt overstappen van labtests met Fio naar razendsnelle productieworkloads in de praktijk.

Vereisten en hulpmiddelen voor het optimaliseren van NVMe op Linux

Voordat u parameters gaat wijzigen, is het essentieel om te beschikken over... toegang wortel naar de server en een goed back-upplanVeel van de instellingen die we zullen bespreken, hebben invloed op de kernel, de partitionering of zelfs de apparaatindeling. Elke fout kan er dus toe leiden dat een service vastloopt of dat een volume onherstelbaar wordt.

Je moet ook beschikken over bepaalde hulpprogramma's voor het beheren van NVMe, het bewaken van I/O en het uitvoeren van benchmarksOp Debian of Ubuntu kun je ze installeren met:

Installatie op Debian/Ubuntu: sudo apt update
sudo apt install nvme-cli fio util-linux iotop sysstat numactl -y

In RHEL-gebaseerde systemen (Rocky, Alma, CentOS, enz.) worden ze als volgt bereikt:

Installatie in RHEL en afgeleiden: sudo dnf update -y
sudo dnf install nvme-cli fio util-linux iotop sysstat numactl -y

Met deze tools kan dat Identificeer uw NVMe-apparaten, controleer hun status en firmware updaten op Linux, meet de latentie en doorvoer Objectief en herhaalbaar, iets cruciaals voordat je iets aanraakt, om de situatie "voor" en "na" te kunnen vergelijken.

Ontdek, identificeer en meet uw NVMe-apparaten.

De eerste stap is om een ​​lijst te maken van de NVMe-schijven die je daadwerkelijk hebt en wat hun specificaties zijn. Je kunt het heel duidelijk zien met nvme-cli en zonder gedoe met rare namen in /dev.

Lijst met NVMe-apparaten: nvme list

Als je dieper wilt graven, toont het volgende commando het NVMe-controllerfunctionaliteiten (wachtrijen van commando's, maximale overdrachtsgrootte, enz.):

Details van de NVMe-controller: nvme id-ctrl -H /dev/nvme0

En om de informatie over de "namespace" te bekijken (LBA-formaten, sectorgroottes en relatieve prestatierangschikking):

Details over de NVMe-naamruimte: nvme id-ns -H /dev/nvme0n1

Voordat je begint met het finetunen van het systeem, is het verstandig om een ​​back-up te maken. Prestatiebasislijn met fioJe kunt bijvoorbeeld de latentie meten bij willekeurige 4K-leesbewerkingen met directe I/O:

Basisbenchmark (fio randread 4K): fio --name=randread --filename=/dev/nvme0n1 --rw=randread --bs=4k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

En de sequentiële leesdoorvoer bij 128K:

Basisbenchmark (fio seqread 128K): fio --name=seqread --filename=/dev/nvme0n1 --rw=read --bs=128k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Om te begrijpen hoe het systeem als geheel zich gedraagt, is het nuttig om dit aan te vullen met iostat en smart-log:

iostat / smart-log controles: iostat -x 2 10
nvme smart-log /dev/nvme0

Op deze manier weet je of het knelpunt zich bevindt in wachtrijtijden, temperatuur, mediafouten of simpelweg in de bovenste laag (bestandssysteem, database, enz.).

NVMe-energiebeheer (APST) voor lage latentie

NVMe-schijven implementeren APST (Autonomous Power State Transition)een mechanisme om energie te besparen door diepere, energiezuinige standen te activeren. Dat is prima voor portableMaar op een server waar wachtrijen van milliseconden of microseconden ertoe doen, kunnen die SSD-"wake-ups" onaangename latency-pieken veroorzaken.

Als je prioriteiten stelt consistente latentie bij energiebesparingenJe kunt APST uitschakelen door de parameter nvme_core van de module aan te passen (zie de kernelnieuwsOp systemen met GRUB is het voldoende om het volgende toe te voegen:

APST uitschakelen (GRUB): sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nvme_core.default_ps_max_latency_us=0 /' /etc/default/grub
sudo update-grub

Na een herstart zal de kernel stoppen met het overschakelen van de schijf naar diepe energiebesparende standen en, in het algemeen, De wachtrijen met een latentie van 99% en 99.9% zouden moeten verbeteren.mits de serverkoeling toereikend is voor de temperatuurstijging.

I/O-scheduler geschikt voor NVMe- en bloklaaginstellingen

De I/O-scheduler is de laag die beslist In welke volgorde worden lees- en schrijfverzoeken verwerkt? richting het apparaat. Bij mechanische schijven was het heel zinvol om complexe schedulers te gebruiken die de fysieke beweging van de leeskoppen optimaliseerden, maar bij NVMe is dat overbodig en kan het zelfs een belemmering vormen.

In de meeste moderne distributies worden NVMe-schijven al gebruikt. scheduler «geen» (of mq-deadline in bepaalde gevallen)Desondanks is het de moeite waard om eens te bekijken:

Controleer de I/O-planner: cat /sys/block/nvme0n1/queue/scheduler

Als u iets anders ziet en uw werkbelasting voornamelijk bestaat uit willekeurige I/O met lage latentie, kunt u de scheduler dwingen om "geen" in te stellen:

Planner forceren naar 'geen': echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

Voor zeer gevarieerde workloads met intensieve schrijfbewerkingen kan "mq-deadline" uitkomst bieden. een betere balans tussen doorvoer en latentie:

Dwing scheduler 'mq-deadline' af: echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

Naast de scheduler biedt de bloklaag nog twee andere belangrijke besturingselementen: vooruit lezen en maximale aanvraaggrootteDe read-ahead-functie (read_ahead_kb) leest meer gegevens "vooraf" dan is opgevraagd. Dit is handig bij lange opeenvolgende toegangspogingen, maar contraproductief bij willekeurige toegangspogingen.

Typische read_ahead_kb-waarden: echo 128 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # cargas aleatorias (BBDD)
echo 4096 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # secuencial grande (backups, vídeo, etc.)

Betreffende de maximale aanvraaggrootte (max_sectors_kb)Het is raadzaam om de afmetingen af ​​te stemmen op de optimale I/O-grootte van het apparaat en de maximale hardwarelimieten niet te overschrijden.

Raadpleeg de optimale I/O-formaten: cat /sys/block/nvme0n1/queue/optimal_io_size
cat /sys/block/nvme0n1/queue/max_hw_sectors_kb

Als je dit weet, kun je een redelijke waarde instellen, bijvoorbeeld 1024 KB:

Stel max_sectors_kb in: sudo sh -c 'echo 1024 > /sys/block/nvme0n1/queue/max_sectors_kb'

Optimaliseer de CPU- en NUMA-affiniteit voor NVMe.

In moderne servers met meerdere CPU's of sockets (NUMA), de De latentie bij geheugen- en apparaattoegang is niet uniform.Een NVMe-schijf bevindt zich fysiek dicht bij een specifiek NUMA-knooppunt. Als de threads die de schijf gebruiken zich op een ander knooppunt bevinden, gaat elke I/O-bewerking via de inter-socketbus, met de bijbehorende latentie.

Daarom is het belangrijk om zowel NVMe-onderbrekingen als de processen die er gebruik van maken te begrijpen. zijn verbonden met hetzelfde NUMA-knooppuntZoek eerst uit welke IRQ's de NVMe-schijf gebruikt:

NVMe IRQ's lokaliseren: grep -i nvme /proc/interrupts

Dan kun je bijvoorbeeld alle IRQ's van nvme0 toewijzen aan cores 0-3:

Wijs IRQ-affiniteit toe aan cores: for i in $(grep -i nvme0 /proc/interrupts | awk -F: '{print $1}'); do
echo 0-3 | sudo tee /proc/irq/$i/smp_affinity_list
done

Wanneer u uw hoofddatabase of -service start, zelfs in virtualisatie met KVM, toepassingen numactl om CPU- en geheugenproblemen op te lossen naar hetzelfde knooppunt:

Start de service met numactl: numactl --cpunodebind=0 --membind=0 tu-binario --tus-opciones

Nog een kleine aanpassing aan de bloklaag is rq_affiniteitDit geeft aan hoe I/O-voltooiingswachtrijen worden verwerkt. Een waarde van 2 zorgt ervoor dat de voltooiing wordt afgehandeld op dezelfde core die het verzoek heeft ingediend, waardoor de cachelocaliteit wordt verbeterd.

Activeer rq_affinity=2: echo 2 | sudo tee /sys/block/nvme0n1/queue/rq_affinity

Zorg ervoor dat NVMe-instellingen permanent worden gewijzigd met udev.

Alle wijzigingen die zijn aangebracht door bestanden in /sys aan te raken. Ze gaan verloren bij het opnieuw opstarten.Om te voorkomen dat je elke keer handmatig scripts moet uitvoeren, is de meest efficiënte aanpak het gebruik van udev-regels die de optimalisatie toepassen zodra de kernel het apparaat detecteert.

Om bijvoorbeeld de scheduler op 'none', rq_affinity op 2 en read_ahead op 128 KB in te stellen voor alle NVMe-schijven, kunt u het volgende maken:

Maak een udev-regel aan voor afstemming: sudo nano /etc/udev/rules.d/60-nvme-tuning.rules

Met de inhoud:

Voorbeeld van een udev-regel: ACTION=="add|change", KERNEL=="nvme*n*", \
ATTR{queue/rq_affinity}="2", \
ATTR{queue/scheduler}="none", \
ATTR{queue/read_ahead_kb}="128"

Vervolgens herlaad je udev en activeer je de regels:

Udev-regels toepassen: sudo udevadm control --reload
sudo udevadm trigger

Als u er ook voor wilt zorgen dat alle geassembleerde eenheden profiteren van Opties zoals noatime of tmpfs voor tijdelijke mappen.Combineer deze regels met een goede /etc/fstab-configuratie, wat ook het aantal schrijfbewerkingen vermindert en de levensduur van SSD's en NVMe-schijven verlengt.

Partitie-uitlijning, logische sector en TRIM op NVMe

Om een ​​NVMe-schijf op de lange termijn optimaal te laten presteren, zijn kernelparameters alleen niet voldoende: logische geometrie van partities en het gebruik van TRIMnoch technologieën zoals de permanente geheugenopslagZe maken wel degelijk een verschil, vooral bij het laden van databases en virtualisatie, waar fragmentatie en overschrijving constant voorkomen.

Het eerste wat u moet doen, is controleren of uw partities uitgelijnd op 1 MiBDit past meestal goed bij de interne geometrie van de meeste moderne SSD's. Met parted kun je een overzichtelijke lay-out creëren:

Uitgelijnde partitionering (gepartitioneerd): sudo parted -s /dev/nvme0n1 mklabel gpt
sudo parted -s /dev/nvme0n1 mkpart primary 1MiB 100%
sudo parted -s /dev/nvme0n1 align-check optimal 1

Bovendien bieden veel NVMe-schijven diverse LBA (LBAF)-formaten met verschillende sectorgroottesDoorgaans 512B en 4K. U kunt de opties en de RP-waarde (Relative Performance) bekijken met:

Bekijk LBA-formaten: nvme id-ns -H /dev/nvme0n1 | grep -E 'LBA Format|Relative'

Als u besluit te veranderen, houd er dan rekening mee dat dit een destructieve operatie waardoor alle inhoud van de schijf wordt gewist. Een voorbeeld van het kiezen van de formatteringsoptie met index 1 zou zijn:

LBA-indeling wijzigen (destructieve bewerking): sudo nvme format /dev/nvme0n1 --lbaf=1

Wat TRIM betreft, is het de bedoeling om de eenheid te laten weten welke blokken geen geldige gegevens meer bevatten, zodat deze... hergebruik ze zonder boete.Controleer eerst met lsblk of het apparaat dit ondersteunt:

Controleer de TRIM-ondersteuning: lsblk --discard

Als je een DISC-GRAN-waarde ziet die niet nul is, betekent dit dat er ondersteuning is. De meeste recente distributies bieden hiervoor ondersteuning. wekelijkse timer van fstrim Dit is de aanbevolen optie, beter dan het gebruik van de discard-optie in /etc/fstab, die extra overhead toevoegt aan elke verwijdering:

Schakel periodieke fstrim in: systemctl enable --now fstrim.timer
systemctl status fstrim.timer

Het kiezen en installeren van bestandssystemen op NVMe

De bestandssysteemlaag vormt het laatste filter tussen uw applicatie en de NVMe-schijf. XFS en ext4 werken erg goed op Linux-servers.In de meeste gevallen is het raadzaam om de standaardinstellingen te gebruiken, met kleine aanpassingen om onnodige schrijfbewerkingen te verminderen.

Een zeer effectieve optie met vrijwel geen nadelen is middagDit voorkomt dat de laatst gebruikte toegangstijd telkens wordt bijgewerkt wanneer een bestand wordt gelezen. Dit vermindert het aantal schrijfbewerkingen naar de schijf, wat zowel de levensduur van bestanden als de prestaties ten goede komt. Een voorbeeld in /etc/fstab met ext4 zou er als volgt uitzien:

Voorbeeld fstab (ext4 noatime): /dev/nvme0n1p1 / ext4 noatime,errors=remount-ro 0 1

Bij XFS is de filosofie hetzelfde: gebruik het standaard bestandssysteem en voeg 'noatime' toe als je de levensduur van de SSD verder wilt verlengen. In het geval van ext4 en XFS is het... Bij voorkeur periodiek TRIM met fstrim.timer in plaats van de optie om het product weg te gooien, behalve in zeer specifieke gevallen.

Als u met SD-kaarten of verwisselbare media werkt, houd er dan rekening mee dat veel gebruikers FAT32 of exFAT, dat Ze hebben geen dagboekfunctie of TRIM.In deze gevallen ligt de focus bij het optimaliseren meer op het kiezen van kaarten met een hogere kwaliteit en capaciteit, en op het minimaliseren van schrijfbewerkingen door /var/log, /tmp of mappen met veel I/O naar tmpfs te verplaatsen wanneer dat zinvol is.

Algemene SSD/NVMe-optimalisatie: noatime, tmpfs, swap en logging

Naast NVMe-specifieke optimalisaties zijn er een aantal klassieke SSD-tweaks die nog steeds erg effectief zijn. De eerste is om te controleren welke mappen de meeste belasting ondervinden. voortdurend lezen en schrijven iotop gebruiken:

Realtime I/O-monitoring: iotop -oPa

Laat het een tijdje draaien en je zult zien welke processen en paden voorrang krijgen. Van daaruit kun je een aantal zeer vluchtige mappen verplaatsen naar tmpfs in RAMmits je voldoende geheugen hebt. Typische voorbeelden in /etc/fstab:

Voorbeeld van tmpfs in fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

In veel moderne Linux-distributies is /tmp al tmpfs, maar je kunt /var/tmp of andere mappen die veel gegevens bevatten nog steeds naar het RAM-geheugen verplaatsen. Een andere optie is /var/log, als je het niet erg vindt om logbestanden te verliezen tussen herstarts of als je de logbestanden naar een externe syslog-server stuurt.

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Bekijk tegelijkertijd de systemd-journal configuratie In /etc/systemd/journald.conf kunt u de maximale loggrootte (SystemMaxUse, RuntimeMaxUse, enz.) en het detailniveau (MaxLevelStore) beperken om onnodige schrijfbelastingen te voorkomen.

Een ander belangrijk punt voor elke SSD of NVMe is het gebruik van ruil- en ruilbaarheidsbeleidDoor deze waarde te verlagen, kan de kernel het RAM-geheugen efficiënter gebruiken en het schijfgebruik verminderen:

Swappyness-aanpassing: vm.swappiness=1

Als je een uitzonderlijk goed geheugen hebt en je bewust bent van het risico, zou je het zelfs op 0 kunnen zetten, hoewel het in de praktijk meestal evenwichtiger is om het te combineren met zram of zswapdie de swap in het geheugen comprimeren en beheren voordat deze de fysieke schijf bereikt, waardoor het aantal schrijfbewerkingen naar de NVMe aanzienlijk wordt verminderd.

Het diagnosticeren van echte problemen versus synthetische benchmarks (fio, dd, bestandskopieën)

Het is niet ongebruikelijk dat een beheerder de volgende situatie tegenkomt: fio levert uitstekende resultaten, maar een simpele bestandskopie of een SELECT INTO-query in een database lijkt tergend traag.Het is cruciaal om te begrijpen dat de belasting in de praktijk geen perfecte maatstaf is en dat er veel meer factoren een rol spelen.

Commando's zoals dd met bs=1M Ze geven meestal snelheden weer die beperkt worden door de bestandssysteemlaag, de kernelpagina-cache, dd zelf en de manier waarop het schrijftOp dezelfde manier meet een grootschalige bewerking in MSSQL, MySQL of MariaDB op ext4 of XFS niet alleen het NVMe-geheugen, maar ook de journaling, fsync, log flush, vergrendeling, CPU, kernel scheduler en nog veel meer.

Als je op een server met Epyc, veel RAM en hoogwaardige NVMe-schijven merkt dat back-ups niet sneller gaan dan 1-2 GB/s, maar Fio waarden rapporteert die dicht bij de specificaties liggen, ligt het knelpunt hoogstwaarschijnlijk in de softwarelaag (bestandssysteem, database, journalingconfiguratie, loggrootte, enz.) of in de manier waarop parallellisme wordt gebruikt (aantal effectieve threads, gelijktijdigheidslimieten in de database, enz.).

De praktische aanpak is om tools op laag niveau (fio, iostat, smart-log) te combineren met metingen op applicatieniveau en pas de instellingen in lagen aan: eerst de kernel en NVMe, dan het bestandssysteem en tenslotte de database en de query's zelf.

De rol van hardware en besturingssysteem in databaseprestaties

Als we het over afstemming hebben, dan hebben we het over stemmen. databanken Wat NVMe betreft, is het cruciaal om te onthouden dat de standaardconfiguratie zelden voldoende is voor een productieomgeving. De prestatiepiramide begint met de hardware.CPU, hoeveelheid RAM en, bovenal, type opslagruimte.

Aan de basis van die piramide bevindt zich de opslagkwaliteitMechanische harde schijven zijn niet langer geschikt voor serieuze transactiedatabases; SATA SSD's zijn het minimaal acceptabele; en NVMe-schijven die via PCIe zijn aangesloten, zijn de gouden standaard dankzij hun lage latentie en zeer hoge IOPS.

Daarboven bevindt zich het besturingssysteem: hoe het dit beheert. geheugen, paginacache, schijf-I/O en procesplanning Het heeft directe invloed op de database. Instellingen zoals swappiness, schedulerselectie, het gebruik van O_DIRECT in InnoDB, NUMA-affiniteit en het mounten van mappen in tmpfs kunnen een groter verschil maken dan een simpele interne parameterwijziging in MySQL.

Pas dan heeft het zin om met de te vechten configuratie van de databaseserver (InnoDB, globale buffers, logboeken, enz.) en, bovenal, het ontwerp van schema's en indexen en de kwaliteit van SQL-query's.

MySQL/MariaDB op NVMe: InnoDB optimaliseren voor maximale hardware-efficiëntie

InnoDB is niet voor niets de moderne standaard voor dataopslag: Het biedt ACID-transacties, vergrendeling op rijniveau, goede weerstand tegen corruptie en de mogelijkheid om hoge gelijktijdigheid te verwerken.Maar om echt te excelleren, moet de configuratie afgestemd zijn op de onderliggende hardware, vooral bij snelle NVMe-schijven.

De sterparameter is innodb_buffer_pool_sizeDit bepaalt hoeveel RAM-geheugen InnoDB reserveert voor het bewaren van veelgebruikte data en indexen in het geheugen. Over het algemeen wordt op een dedicated databaseserver tussen de 70% en 80% van het beschikbare RAM-geheugen gereserveerd voor de bufferpool, afhankelijk van de andere services die op de machine draaien.

Wanneer de gegevens voornamelijk in de bufferpool passen, worden leesbewerkingen in het RAM-geheugen afgehandeld en wordt NVMe hoofdzakelijk gebruikt voor sequentiële logboekschrijvingen en gecontroleerd doorspoelenAnders gezegd, elke cache-miss vereist een schijfbezoek, zelfs als het een NVMe-schijf is. de tijd De reactietijd zal vele malen langer zijn dan bij een geheugentoegang.

Het andere belangrijke afstemmingsblok is de InnoDB-logbestanden (innodb_log_file_size en innodb_log_buffer_size)Een logbestand met de juiste afmetingen maakt het mogelijk om meer wijzigingen te groeperen in lange, opeenvolgende schrijfbewerkingen, waardoor de druk van willekeurige I/O op gegevensbestanden wordt verminderd:

• Groot logbestand: Hogere schrijfprestaties, maar langere hersteltijden na een crash, omdat meer gebeurtenissen opnieuw moeten worden afgespeeld.
• Klein logbestand: Sneller herstel, maar mogelijk een knelpunt bij intensief schrijven.

Om optimaal te profiteren van NVMe is het meestal de moeite waard om te beschikken over boomstammen iets groter dan gebruikelijkomdat de schijf probleemloos opeenvolgende schrijfbewerkingen aankan en de hersteltijd doorgaans nog acceptabel is.

Gelijktijdigheid, threads en I/O in InnoDB over NVMe

In omgevingen met veel CPU's en snelle NVMe-schijven is het verleidelijk om parameters zoals aan te passen. innodb_thread_concurrency, innodb_read_io_threads en innodb_write_io_threadsIn de huidige versies van MySQL/MariaDB is het echter gebruikelijk om innodb_thread_concurrency op 0 te laten staan, zodat de engine zelf de interne gelijktijdigheid beheert.

Het belangrijkste is ervoor te zorgen dat de server niet zonder schijfruimte komt te zitten. threads voor lees- en schrijfbewerkingen En dat de onderliggende laag (kernel en NVMe) voorbereid is om diepe I/O-wachtrijen af ​​te handelen wanneer de belasting dit daadwerkelijk vereist. Met NVMe is er meestal geen probleem, maar het is raadzaam om tools zoals Performance Schema of sys schema te gebruiken om te controleren op afwijkende I/O-wachttijden.

De manier waarop InnoDB met het bestandssysteem communiceert, is ook cruciaal. De parameter innodb_flush_method=O_DIRECT In Linux wordt dubbele buffering met de bestandssysteemcache vermeden en wordt er direct naar het apparaat geschreven. Dit is met name aan te raden bij RAID met een beveiligde cache of NVMe met een goede interne cache.

Verbindingsbeheer, sessiebuffers en globale caches

Snelle NVMe-schijven zijn niet erg nuttig als de databaseserver overbelast is. Duizenden inactieve verbindingen, gigantische sessiebuffers of een verouderde querycacheconfiguratie.Naast het afstemmen van InnoDB is het daarom noodzakelijk om de algemene parameters te organiseren.

veranderlijk max_connections Definieert het maximale aantal gelijktijdige verbindingen dat is toegestaan. Het blindelings verhogen ervan omdat "er genoeg RAM is" is een fout: elke verbinding sleept buffers en interne structuren mee die zich in het geheugen ophopen. De beste werkwijze is om Max_used_connections te monitoren. Stel max_connections iets hoger in dan de werkelijke piekwaarde.Ruimte overlaten, maar niet overdrijven.

`wait_timeout` specificeert hoe lang een inactieve verbinding actief blijft voordat deze wordt gesloten. Standaardwaarden in uren zijn in deze context niet erg zinvol. webapplicaties met verbindingspoolsDoor de time-out te verkorten tot 60 of zelfs 30 seconden worden afgebroken sessies gewist en wordt voorkomen dat het geheugen vol raakt met "slapende" verbindingen.

Parameter thread_cache_size Deze instelling bepaalt hoeveel threads in de cache worden opgeslagen voor hergebruik bij nieuwe verbindingen. Als Threads_created aanzienlijk hoger is dan Connections, duidt dit op een kleine cache. Het aanpassen van deze instelling verlaagt de kosten voor het aanmaken van threads en verbetert de responsiviteit tijdens pieken in het verkeer.

Wat de querycache betreft, deze is verouderd in moderne MySQL en ontbreekt meestal in MariaDB. veroorzaken meer blokkades en invalidatieproblemen dan voordelen. Op systemen met hoge schrijfsnelheden biedt het geen extra voordelen ten opzichte van NVMe, en in de meeste gevallen is het beter om het uit te schakelen.

Werkbuffers per sessie: wees voorzichtig met het geheugen.

Parameters zoals sort_buffer_size, join_buffer_size en read_buffer_size Ze worden per thread toegewezen wanneer dat nodig is, wat betekent dat enorme waarden vermenigvuldigd met honderden verbindingen het RAM-geheugen bij volle snelheid volledig kunnen opslokken.

Deze buffers worden gebruikt voor specifieke bewerkingen (sorteren zonder index, samenvoegen zonder index, sequentiële leesbewerkingen) en mogen slechts gedurende een bepaalde tijd worden vergroot. specifieke gevallen van intensieve en gecontroleerde consultatiesWereldwijd is het beter om conservatieve waarden aan te houden en deze, indien nodig, per geval te verhogen tijdens een onderhoudssessie of batchproces, in plaats van enorme limieten te stellen voor alle klanten.

Schema-, index- en query-ontwerp: de laag waar de meeste winst te behalen valt.

Hoeveel NVMe, kerneloptimalisatie en InnoDB je ook hebt, als je tabellen niet werken, zal het niet lukken. Voer met behulp van geschikte indexen en zoekopdrachten volledige, grootschalige scans uit.De hardware kan je niet redden. De essentiële tool om te zien wat er aan de hand is, is EXPLAIN.

Bij het analyseren van een uitvoeringsplan dient u op het volgende te letten:

• Type: Als je in grote tabellen 'ALL' ziet staan, is er een volledige scan uitgevoerd en moet je indexen toevoegen.
• sleutel en mogelijke_sleutels: welke indexen gebruikt zouden kunnen worden en welke daadwerkelijk gebruikt wordt.
• rijen: Geschat aantal rijen om te onderzoeken; hoe lager, hoe beter.

Correct indexeren is essentieel. de kolommen die worden gebruikt in de WHERE- en JOIN-voorwaarden...en het herschrijven van gecorreleerde subquery's in JOINs waar mogelijk. Een goed indexontwerp vermindert de benodigde I/O per query en benut zo de lage latentie van NVMe beter.

Gebruik op schematisch niveau het volgende: gegevenstypen zo klein mogelijkNormaliseren naar een redelijk niveau en het definiëren van eenvoudige primaire sleutels (INT/BIGINT AUTO_INCREMENT) in InnoDB helpt tabellen compacter te maken, beter in de bufferpool te passen en optimaal gebruik te maken van de cache en de onderliggende hardware.

Continue monitoring en iteratieve afstemmingscyclus

Al dat afstellen is zinloos als het niet Je meet voor en na van elke wijziging. Voor de database kunt u met behulp van het Slow Query Log, Performance Schema en sys schema trage query's, tabellen met veel volledige scans, onderbenutte indexen of bestanden die te veel I/O concentreren, lokaliseren.

Externe hulpmiddelen zoals Prometheus/Grafana, Percona PMM of andere monitoringsystemen Ze maken het gemakkelijker om het grotere plaatje te zien: gemiddelde latentie en p95/p99-query's, QPS, CPU-gebruik, I/O-wachtrijen, NVMe-temperatuur en -status, enz. Met die informatie kunt u een zinvol iteratief proces toepassen:

• Definieer een prestatiebasislijn (hardware + kernel + database).
• Identificeer het belangrijkste knelpunt op dat moment.
• Voer één enkele wijziging door (bijvoorbeeld de bufferpool aanpassen, de scheduler wijzigen of een index toevoegen).
• Meet opnieuw en bepaal of de verandering blijft, wordt teruggedraaid of wordt aangepast.

Het optimaliseren van NVMe en databases op Linux is geen tovertruc of een kwestie van een enkele parameterwijziging, maar een continu proces van meten, begrijpen en aanpassen in lagenDoor goede hardware (met name hoogwaardige NVMe), een goed afgestelde kernel (APST, scheduler, NUMA, TRIM), intelligent geconfigureerde bestandssystemen (noatime, tmpfs waar nodig) en een goed geparameteriseerde MySQL/MariaDB met solide schema's en indexen te combineren, is het perfect mogelijk om uw Linux-servers het volledige potentieel van hun NVMe-schijven te laten benutten onder realistische werkbelastingen, en niet alleen in synthetische laboratoriumbenchmarks.