Debian 12 draaien op een VPS met weinig RAM zonder geheugenproblemen die MySQL platleggen.

Een VPS met weinig geheugen kan Debian 12 en een database draaien, maar de stabiliteit hangt af van de totale werklast – niet alleen van de geconfigureerde cache van MySQL. Wanneer het beschikbare geheugen opraakt, kan Linux de out-of-memory (OOM) killer activeren, die een proces beëindigt om de rest van het systeem te beschermen. Als dat proces de database is, kan het symptoom lijken op een willekeurige crash. Het praktische doel is om aanhoudende geheugenproblemen te voorkomen en te bevestigen wat de kernel daadwerkelijk heeft beëindigd; geen enkele instelling kan garanderen dat OOM-gebeurtenissen nooit zullen optreden.

Draait Debian 12 op MySQL of MariaDB?

Controleer de server voordat u de configuratie wijzigt. Debian 12 (Bookworm) gebruikt MariaDB als standaardpakket default-mysql-server; Oracle MySQL is een aparte installatie. De pakketinformatie van Debian vermeldt MariaDB als serverafhankelijkheid van dat metapakket. Voer het volgende commando uit:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

Gebruik de onderstaande MariaDB-instructies alleen als MariaDB is geïnstalleerd. Oracle MySQL gebruikt in veel gevallen compatibel ogende optienamen, maar pakketstructuren, servicenamen, beschikbare variabelen en standaardwaarden kunnen verschillen. Raadpleeg de handleiding voor de exacte MySQL-versie die is geïnstalleerd.

Primaire referenties: het default-mysql-server-pakket van Debian Bookworm en de MySQL 8.0 memory-use-handleiding .

Hoe kun je vaststellen of de database door een geheugenprobleem (OOM) is vastgelopen?

Onderscheid eerst een kernel OOM kill van een databasefout, een herstart van een service, een herstart van het systeem of een schijfprobleem. Op Debian journalctlleest u het logboek van systemd. Zoek in de huidige opstartgegevens en inspecteer het servicelogboek van MariaDB:

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

Als de kernel in het logboek een OOM-bericht (Out of Memory) mariadbdweergeeft mysqld, is dat een teken dat het geheugen is vastgelopen. Als er geen overeenkomende vermelding is, controleer dan het foutenlogboek van de service zelf en de herstart- of monitoringgeschiedenis van de provider. Logboeken zijn mogelijk niet beschikbaar na een herstart als de logboekregistratie niet persistent is, en een managed VPS-provider toont mogelijk slechts een deel van de diagnostische gegevens van de host.

Leg een basislijn vast terwijl de server representatief verkeer verwerkt, niet alleen wanneer deze inactief is:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

In de logbestanden vmstatmoet je de kolommen sien in de gaten houden sovoor aanhoudende swap-in- en swap-out-activiteit. Een swap-allocatie die niet nul is, is op zich geen probleem; aanhoudend swappen in combinatie met trage reactietijden duidt op geheugenproblemen. Linux beschrijft de afhandeling van OutOfMemoryError (OOM) als een laatste redmiddel wanneer er onvoldoende geheugen kan worden vrijgemaakt. Zie de documentatie over geheugenbeheer in de Linux-kernel en de journalctl-handleiding van Debian .

Wat moet je meten voordat je gaat stemmen?

Registreer het totale RAM-geheugen, het huidige en piekgebruik van de swap, de grootste actieve processen, databaseverbindingen en de normale piek van de webapplicatie. De database deelt geheugen met Debian, de webserver, applicatieworkers, monitoringagents en de bestandssysteemcache. Een VPS kan ook een lagere geheugenlimiet hebben voor containers of cgroups dan het fysieke RAM-geheugen van de host; de grootte van de databasecache wordt aangepast aan de geheugenlimiet die zichtbaar is voor de service, niet aan een grotere totale limiet van de host.

Controleer voor MariaDB de huidige geheugeninstellingen en de piekbelasting van de verbindingen:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

De bufferpool van InnoDB cachet tabel- en indexpagina's. Verbindingslimieten en querybuffers kunnen de geheugenbehoefte verhogen naarmate het aantal gelijktijdige taken toeneemt. Vermijd het vermenigvuldigen van elke buffer per verbinding max_connectionsalsof elke buffer altijd volledig is toegewezen, maar beschouw een zeer hoge verbindingslimiet wel als een risico tijdens piekbelastingen. De geheugenhandleiding van MariaDB adviseert om globale caches, buffers per verbinding en engine-instellingen gezamenlijk te dimensioneren en wijst specifiek op applicatieverbindingspools. Lees de handleiding voor geheugentoewijzing van MariaDB en de handleiding voor het omgaan met te veel verbindingen .

Hoe optimaliseer je MariaDB voor een kleine VPS?

Voer één wijziging tegelijk door, bewaar een kopie van de oorspronkelijke configuratie en test tijdens een onderhoudsvenster of een herstart gevolgen zou hebben voor gebruikers. De MariaDB-configuratie die bij Debian wordt geleverd, bevat doorgaans bestanden in de map /etc/mysql/mariadb.conf.d/; controleer de actieve include-directory's op uw installatie voordat u wijzigingen aanbrengt. Een klein drop-in-bestand is gemakkelijker te verwijderen dan het hoofdbestand van de leverancier te vervangen:

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

Voor een gedeelde VPS met ongeveer 1 GiB RAM is het volgende slechts een voorzichtig uitgangspunt en geen universeel veilig profiel. Verlaag of verhoog de waarden op basis van het gemeten piekgeheugen, de databasegrootte, de werkbelasting en het resterende RAM-geheugen voor het besturingssysteem en de applicatie:

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB leest bij het opstarten instellingen uit optiebestanden; controleer de ondersteunde sectienamen en effectieve waarden voor uw versie. Als dit bestand niet kan worden geladen, verwijder dan de drop-in en controleer het logboek. Het herstarten van de database verbreekt bestaande verbindingen, dus plan dit op het juiste moment in.

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

Beoordeel het resultaat op basis van zowel stabiliteit als servicekwaliteit. Een kleinere bufferpool kan het aantal cachehits verminderen en het aantal schijfleesbewerkingen verhogen. Een max_connectionste grote verlaging kan echter leiden tot fouten zoals "Te veel verbindingen". Vergelijk de resultaten Max_used_connectionsmet de geconfigureerde limiet en controleer de grootte van de applicatiepool voordat u deze limiet opnieuw wijzigt. Als de database nog steeds vastloopt tijdens normale piekbelasting, of als de responstijd verslechtert door aanhoudend schijfswapping, schakel dan over naar een grotere RAM-laag of scheid de database van de applicatie.

Kan swapping een OOM-crash voorkomen?

Swap biedt Linux een langzamere plek om geheugenpagina's te verplaatsen en kan een korte piekbelasting opvangen. Het voegt geen snel RAM-geheugen toe, lost geen geheugenlekken op en maakt een onderbemeten VPS niet geschikt voor een langdurige werkbelasting. Intensief swappen kan ervoor zorgen dat zowel de database als de applicatie niet meer reageren. Controleer of uw provider swapbestanden ondersteunt en of de VPS voldoende schijfruimte heeft voordat u er een aanmaakt.

Indien ondersteund, kan een swapbestand van 1 GiB als volgt worden aangemaakt. Pas de grootte aan volgens de richtlijnen van de provider en de beschikbare schijfruimte, en controleer het resultaat van elke opdracht:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Om dit na een herstart in te schakelen, voegt u deze vermelding toe /etc/fstabnadat u hebt gecontroleerd of er niet al een overeenkomstige vermelding aanwezig is:

/swapfile none swap sw 0 0

Valideer vervolgens het bestand sudo findmnt --verify --verboseen controleer of het in voorkomt swapon --show. Als fallocatehet bestand niet wordt ondersteund door het bestandssysteem of als de provider swap blokkeert, stop dan en gebruik de door de provider ondersteunde procedure. Schakel de OOM killer niet uit en ken geen extreem hoge OOM-beveiligingsscore toe aan MySQL: dit maakt geen geheugen vrij en kan de rest van een kleine VPS juist meer risico's opleveren.

Hoe weet je of de veranderingen effect hebben gehad?

Observeer de VPS gedurende ten minste één normale, drukke periode. Een nuttig resultaat heeft verschillende kenmerken:

• Er zijn geen nieuwe kernel OOM-kill-meldingen verschenen tijdens de workload die eerder het incident veroorzaakte.
• MariaDB blijft actief en het aantal herstarts loopt niet onverwacht op.
• vmstat 1Onder normale omstandigheden is er geen sprake van continue wisseling van componenten.
• De applicatie blijft responsief en de piekbelasting van de databaseverbindingen blijft onder de nieuwe limiet zonder verbindingsfouten.
• De back-ups zijn voltooid en de databasequery's worden voortgezet binnen de acceptabele latentie van de applicatie.

Gebruik "de service start" niet als enige succesindicator. Een instelling die MariaDB actief houdt maar het systeem constant laat swappen, lost het onderliggende capaciteitsprobleem niet op. Evenzo is één rustige dag geen garantie voor een maandelijkse import, back-up, verkeerspiek of batchtaak die nog niet is uitgevoerd.

Wanneer is afstellen niet langer de juiste oplossing?

Kies een grotere VPS of scheid de workloads wanneer het geheugen onder druk blijft staan ​​na redelijke aanpassingen aan de cache en gelijktijdigheid, de swapactiviteit aanhoudt, de querylatentie onacceptabel wordt of de applicatie herhaaldelijk de nieuwe verbindingslimiet bereikt. De databasegrootte is ook van belang: een te kleine bufferpool kan een geheugenpiek voorkomen, terwijl schijf-I/O de nieuwe bottleneck wordt. Als de applicatie en de database scherpe maar voorspelbare pieken vertonen, bepaal dan eerst of de applicatie te veel verbindingen opent of gelijktijdig geheugenintensieve taken uitvoert.

Controleer bij Oracle MySQL in plaats van de standaard MariaDB van Debian de servicenaam, het pad naar het optiebestand en de geheugenvariabelen aan de hand van de handleiding van die server voordat u deze voorbeelden toepast. Bewaar bij beide databasesystemen geteste back-ups en wijzig slechts één variabele tegelijk. Het betrouwbare resultaat is geen garantie dat Linux nooit een OOM-fout zal veroorzaken; het is een bewijs dat de VPS voldoende capaciteit heeft voor de werkelijke piekbelasting en dat MySQL of MariaDB niet langer het terugkerende slachtoffer is.

Aanvullende primaire referenties: de handleiding voor het oplossen van opstartproblemen van MariaDB , waarin wordt vermeld dat de server ook geheugen nodig heeft voor andere engines, buffers per verbinding en het besturingssysteem, en de MySQL 8.0 Referentiehandleiding .