MySQL crasht tijdens maken van een export - Serversoftware en clouddiensten

woensdag 21 oktober 2015 16:00

Acties:

Moderator SSC/PB

Moooooh!

Topicstarter

Ik draai MySQL 5.5.44 op Ubuntu LTS 14.04.3. Als ik een dump van een database maak met mysqldump dan crasht de mysql service na een tijdje. Dit gebeurt niet op hetzelfde punt, soms aan het begin en soms al halverwege. Maar al met al heb ik al een tijdje geen back-up van de database kunnen maken.

In de /var/log/mysql/err.log staat alleen dit:

code:

151021 13:24:34 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
151021 13:24:34 [Note] Plugin 'FEDERATED' is disabled.
151021 13:24:34 InnoDB: The InnoDB memory heap is disabled
151021 13:24:34 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151021 13:24:34 InnoDB: Compressed tables use zlib 1.2.8
151021 13:24:34 InnoDB: Using Linux native AIO
151021 13:24:34 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
151021 13:24:34 InnoDB: Completed initialization of buffer pool
151021 13:24:34 InnoDB: Fatal error: cannot allocate memory for the buffer pool
151021 13:24:34 [ERROR] Plugin 'InnoDB' init function returned error.
151021 13:24:34 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151021 13:24:34 [ERROR] Unknown/unsupported storage engine: InnoDB
151021 13:24:34 [ERROR] Aborting

151021 13:24:34 [Note] /usr/sbin/mysqld: Shutdown complete

151021 13:24:35 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
151021 13:24:35 [Note] Plugin 'FEDERATED' is disabled.
151021 13:24:35 InnoDB: The InnoDB memory heap is disabled
151021 13:24:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151021 13:24:35 InnoDB: Compressed tables use zlib 1.2.8
151021 13:24:35 InnoDB: Using Linux native AIO
151021 13:24:35 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
151021 13:24:35 InnoDB: Completed initialization of buffer pool
151021 13:24:35 InnoDB: Fatal error: cannot allocate memory for the buffer pool
151021 13:24:35 [ERROR] Plugin 'InnoDB' init function returned error.
151021 13:24:35 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151021 13:24:35 [ERROR] Unknown/unsupported storage engine: InnoDB
151021 13:24:35 [ERROR] Aborting

151021 13:24:35 [Note] /usr/sbin/mysqld: Shutdown complete

Voor zover ik kan zien gaat dit vooral over het starten van de database, ik kan er niet gelijk de oorzaak van de crash uithalen. Die InnoDB melding zie ik al heel lang, heb daar eigenlijk nooit aandacht aan besteed.
Nu MySQL weer draait is dit het geheugengebruik:

code:

root@host:/var/log/mysql# free -m
             total       used       free     shared    buffers     cached
Mem:           670        615         54         64          9        208
-/+ buffers/cache:        398        272
Swap:            0          0          0

Als deze gecrasht is en dus weer opnieuw moet starten:

code:

root@host:/var/log/mysql# free -m
             total       used       free     shared    buffers     cached
Mem:           670        441        228         64         12        111
-/+ buffers/cache:        317        353
Swap:            0          0          0

Lijkt mij genoeg om die 128 MB InnoDB cache te pakken.

Iemand een idee hoe ik de oorzaak van deze crashes kan achterhalen?

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 16:05

Acties:

jbdeiman

Ik zie het volgende staan:
InnoDB: mmap(137363456 bytes) failed; errno 12

Googlen op mmap failed errno 12 innodb, zie ik onderstaande link staan. Denk dat je er wel wat mee kan.

http://stackoverflow.com/...p-x-bytes-failed-errno-12

[ Voor 43% gewijzigd door jbdeiman op 21-10-2015 16:06 ]

woensdag 21 oktober 2015 16:06

Acties:

S_tef

Al Gegooglet?

Je hebt te weinig geheugen voor je config, je hebt 3 opties:
- Je config verlagen;
- Meer geheugen toevoegen aan server / vps;
- Swap beschikbaar maken.

woensdag 21 oktober 2015 16:24

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

Free geeft aan dat er 228 MB beschikbaar is en als ik mysql vervolgens handmatig start dan gaat dat prima.

code:

151021 14:00:01 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
151021 14:00:01 [Note] Plugin 'FEDERATED' is disabled.
151021 14:00:01 InnoDB: The InnoDB memory heap is disabled
151021 14:00:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151021 14:00:01 InnoDB: Compressed tables use zlib 1.2.8
151021 14:00:01 InnoDB: Using Linux native AIO
151021 14:00:01 InnoDB: Initializing buffer pool, size = 128.0M
151021 14:00:01 InnoDB: Completed initialization of buffer pool
151021 14:00:01 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151021 14:00:01  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
151021 14:00:02  InnoDB: Waiting for the background threads to start
151021 14:00:03 InnoDB: 5.5.44 started; log sequence number 31956517
151021 14:00:03 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151021 14:00:03 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
151021 14:00:03 [Note] Server socket created on IP: '0.0.0.0'.
151021 14:00:03 [Note] Event Scheduler: Loaded 0 events
151021 14:00:03 [Note] /usr/sbin/mysqld: ready for connections.

Dus onder normale omstandigheden is er voldoende geheugen om MySQL te starten en kan de InnoDB cache van 128 MB gewoon geclaimd worden. Maar wanneer MySQL na een crash zelf probeert te herstarten dan lukt dat blijkbaar niet.

Wat nog onduidelijk is waarom MySQL überhaupt crasht, dat wordt blijkbaar niet gelogd. Ik zal nog wel eens een backup maken en dan met free kijken of hij uit zijn geheugen loopt.

Edit: Bovenstaande redenering klopt. Als de dump start dan daalt het beschikbaar geheugen tot ongeveer 50 MB, na de crash duurt het een paar seconden voor er weer 150-200 MB vrij is. In dit tijd heeft MySQL twee keer geprobeerd te restarten maar dit lukt niet omdat die 128 MB nog niet beschikbaar is. Kort daarna kan hij wel gewoon herstarten.

Dan blijft dus de vraag waarom MySQL crasht.

[ Voor 8% gewijzigd door Jazzy op 21-10-2015 16:31 ]

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 16:31

Acties:

jbdeiman

Hoi Jazzy

In elk geval lijkt er wel wat corrupt: Je ziet (voor de melding "Database was not shut down normally!" niet echt een error melding staan, maar het is wel een error:

http://dba.stackexchange....innodb-log-files-are-lost

Misschien dat je daar mee uit de voeten kan, in elk geval houdt MySQL op meer dan 1 plek e.e.a. bij ten aanzien van de InnoDB database (of tabellen). Blijkbaar is er ergens een fout ontstaan (ooit) waardoor dit niet meer klopt.

Of (een wat drastischer ingreep):
http://stackoverflow.com/...sql-innodb-keeps-crashing

Wellicht even een kopietje maken wat alles wat met je database te maken heeft, zodat je e.e.a terug kan plaatsen en niet volledig kwijt bent voordat je tot een dergelijke actie overgaat.

Verder hoeft een geheugen issue niet te maken te hebben met dat MySQL over zijn max toegewezen geheugen komt, maar kan ook zijn dat het systeem niet meer geheugen beschikbaar heeft (of stelt) voor MySQL om zijn werk te kunnen doen. Wanneer MySQL zelf 'out of memory' gaat kan je dat vaak wel terugzien in de logs.

[ Voor 29% gewijzigd door jbdeiman op 21-10-2015 16:33 ]

woensdag 21 oktober 2015 16:43

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

jbdeiman schreef op woensdag 21 oktober 2015 @ 16:31:Verder hoeft een geheugen issue niet te maken te hebben met dat MySQL over zijn max toegewezen geheugen komt, maar kan ook zijn dat het systeem niet meer geheugen beschikbaar heeft (of stelt) voor MySQL om zijn werk te kunnen doen. Wanneer MySQL zelf 'out of memory' gaat kan je dat vaak wel terugzien in de logs.

Welke logs? Want dit is precies waar ik naar op zoek ben. Ik denk dat het inderdaad klopt dat andere processen (apache) teveel geheugen claimen en dat dit de oorzaak is van de MySQL crashes, maar het zit me niet lekker dat dit nergens gelogd lijkt te worden. Of ik zit dus niet goed met /var/log/mysql/err.log.

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 16:47

Acties:

jbdeiman

Jazzy schreef op woensdag 21 oktober 2015 @ 16:43:
[...]
Welke logs? Want dit is precies waar ik naar op zoek ben. Ik denk dat het inderdaad klopt dat andere processen (apache) teveel geheugen claimen en dat dit de oorzaak is van de MySQL crashes, maar het zit me niet lekker dat dit nergens gelogd lijkt te worden. Of ik zit dus niet goed met /var/log/mysql/err.log.

Dat is het lastige volgens mij ook, weet niet 100 % zeker hoe dit zit, maar heb ergens ooit gelezen dat:
- Wanneer MySQL meer vraagt (aan geheugen) dan wat volgens de config is ingesteld, dan zie je dat terug. Vraagt het meer geheugen aan het systeem, maar heeft die dat niet beschikbaar zit de crash op een ander niveau.

Overigens zou ik me vooral gaan focussen op onderstaande meldingen:

InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!

woensdag 21 oktober 2015 17:02

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

jbdeiman schreef op woensdag 21 oktober 2015 @ 16:47:
[...]

Dat is het lastige volgens mij ook, weet niet 100 % zeker hoe dit zit, maar heb ergens ooit gelezen dat:
- Wanneer MySQL meer vraagt (aan geheugen) dan wat volgens de config is ingesteld, dan zie je dat terug. Vraagt het meer geheugen aan het systeem, maar heeft die dat niet beschikbaar zit de crash op een ander niveau.

Overigens zou ik me vooral gaan focussen op onderstaande meldingen:

InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!

Zijn die niet gewoon het gevolg van het feit dat MySQL gecrashed is en er dus recovery nodig is? Want als ik de service netjes stop en start staan die regels er niet bij:

code:

151021 15:01:20 [Note] /usr/sbin/mysqld: Normal shutdown

151021 15:01:20 [Note] Event Scheduler: Purging the queue. 0 events
151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 971  user: 'azureuser'

151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 965  user: 'azureuser'

151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 699  user: 'azureuser'

151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 681  user: 'azureuser'

151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 267  user: 'azureuser'

151021 15:01:22 [Warning] /usr/sbin/mysqld: Forcing close of thread 245  user: 'azureuser'

151021 15:01:22  InnoDB: Starting shutdown...
151021 15:01:24  InnoDB: Shutdown completed; log sequence number 31964977
151021 15:01:24 [Note] /usr/sbin/mysqld: Shutdown complete

151021 15:01:24 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
151021 15:01:24 [Note] Plugin 'FEDERATED' is disabled.
151021 15:01:24 InnoDB: The InnoDB memory heap is disabled
151021 15:01:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151021 15:01:24 InnoDB: Compressed tables use zlib 1.2.8
151021 15:01:24 InnoDB: Using Linux native AIO
151021 15:01:24 InnoDB: Initializing buffer pool, size = 128.0M
151021 15:01:24 InnoDB: Completed initialization of buffer pool
151021 15:01:24 InnoDB: highest supported file format is Barracuda.
151021 15:01:25  InnoDB: Waiting for the background threads to start
151021 15:01:26 InnoDB: 5.5.44 started; log sequence number 31964977
151021 15:01:26 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151021 15:01:26 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
151021 15:01:26 [Note] Server socket created on IP: '0.0.0.0'.
151021 15:01:26 [Note] Event Scheduler: Loaded 0 events
151021 15:01:26 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Dat is wel knap lastig troubleshooten trouwens, als MySQL het niet in de logs meldt dat hij crasht wegens geheugengebrek.

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 17:21

Acties:

synoniem

Het lijkt er toch sterk op dat MySQL geheugen tekort komt. De simpelste oplossing daarvoor is om swap geheugen aan te zetten wat je zo aan je free commando te zien nu niet in gebruik hebt. Om met beschikbaar swap geheugen te testen kun je de volgende commando's gebruiken

code:

1
2
3

dd if=/dev/zero of=/home/user/swapfile bs=1M count=1024
mkswap /home/user/swapfile 
swapon /home/user/swapfile

Werkt dat goed dan kan je eventueel permanent een swap partitie aanmaken.

woensdag 21 oktober 2015 18:26

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

synoniem schreef op woensdag 21 oktober 2015 @ 17:21:
Het lijkt er toch sterk op dat MySQL geheugen tekort komt.

Waar blijkt dat uit? Ik zeg niet dat je ongelijk hebt, maar ik zou zo graag willen meten en begrijpen wat er gebeurt.

De simpelste oplossing daarvoor is om swap geheugen aan te zetten wat je zo aan je free commando te zien nu niet in gebruik hebt.

Dat is misschien het simpelste, maar ik ga eerst even kijken of ik MySQL en Apache een beetje kan temmen qua geheugengebruik. Deze server draait een klein phpBB forum en zou dat makkelijk moeten kunnen met deze configuratie. Resources toevoegen, hetzij echte resources, hetzij swap, kan altijd nog.

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 19:21

Acties:

Wim-Bart

Zie signature voor een baan.

Je innodb initialiseerd maar half als ik je log zie. Hij lijkt het te doen en zal ook werken, totdat hij belast wordt. Een dump vreet veel resources en mysqld zal al crashen vanwege memory resource problemen voordat hij in staat is een log entry weg te schrijven. Probeer je memory parameters naar beneden bij te schroeven in de ini file.

Beheerders, Consultants, Servicedesk medewerkers. We zoeken het allemaal. Stuur mij een PM voor meer info of kijk hier De mooiste ICT'er van Nederland.

woensdag 21 oktober 2015 19:29

Acties:

synoniem

Jazzy schreef op woensdag 21 oktober 2015 @ 18:26:
[...]
Waar blijkt dat uit? Ik zeg niet dat je ongelijk hebt, maar ik zou zo graag willen meten en begrijpen wat er gebeurt.

Dat is een educated quess vanwege de combinatie "151021 15:01:24 InnoDB: The InnoDB memory heap is disabled" en "151021 13:24:34 InnoDB: Initializing buffer pool, size = 128.0M InnoDB: mmap(137363456 bytes) failed; errno 12"
De eerste melding betekent dat MySQL het geheugenbeheer aan het systeem over laat en de tweede is de melding dat hij geheugen tekort komt. Ergo je hebt te weinig geheugen en het systeem kan niet meer alloceren want hij heeft geen swap. Op het moment dat Apache een workersessie opstart gebruikt die ook de nodige Mb's, goede kans dus dat dit met enige regelmaat zal gebeuren.

woensdag 21 oktober 2015 19:53

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

synoniem schreef op woensdag 21 oktober 2015 @ 19:29:
[...]

Dat is een educated quess vanwege de combinatie "151021 15:01:24 InnoDB: The InnoDB memory heap is disabled" en "151021 13:24:34 InnoDB: Initializing buffer pool, size = 128.0M InnoDB: mmap(137363456 bytes) failed; errno 12"
De eerste melding betekent dat MySQL het geheugenbeheer aan het systeem over laat en de tweede is de melding dat hij geheugen tekort komt. Ergo je hebt te weinig geheugen en het systeem kan niet meer alloceren want hij heeft geen swap. Op het moment dat Apache een workersessie opstart gebruikt die ook de nodige Mb's, goede kans dus dat dit met enige regelmaat zal gebeuren.

Die 128 MB kan hij alleen niet alloceren direct na de crash, na een paar seconden wordt het geheugen vrijgegeven en kan MySQL gewoon weer starten en ook die cache van 128 MB aanmaken.

Ik ben het wel eens met jullie opmerkingen dat MySQL tegen een gebrek aan geheugen aanloopt, ik vind het alleen irritant dat we dat blijkbaar niet met zekerheid kunnen vaststellen. Een tweede is of het aanmaken van swap de beste oplossing is of dat MySQL en Apache gewoon wat minder geheugen moeten gebruiken. Want niemand vraagt wat de load van de servers is en of het logisch is om (al dan niet virtuele) resources toe te voegen.

Wat ik nu ga doen is Apache tunen en MySQL. Ben begonnen met MySQL aan de hand van dit script: https://launchpad.net/mysql-tuning-primer De InnoDB cache wordt maar voor 9% gebruikt dus die pas ik aan naar 32MB en max_connections zet ik op 100 om te voorkomen dat er teveel geheugen gereserveerd wordt.

Exchange en Office 365 specialist. Mijn blog.

woensdag 21 oktober 2015 20:07

Acties:

Brahiewahiewa

boelkloedig

Wat is er tegen een swap file?

QnJhaGlld2FoaWV3YQ==

woensdag 21 oktober 2015 20:12

Acties:

donderdraak

Doe eens df -h
Misschien heb je daar teweinig schrijfruimte?

woensdag 21 oktober 2015 23:10

Acties:

synoniem

Op het moment dat je met een tijdelijke swapfile geen geheugenprobleem hebt, kan je met redelijke mate van zekerheid vaststellen dat het puur een geheugenruimte probleem is,

donderdag 22 oktober 2015 01:10

Acties:

Jazzy

Moderator SSC/PB

Moooooh!

Topicstarter

Brahiewahiewa schreef op woensdag 21 oktober 2015 @ 20:07:
Wat is er tegen een swap file?

Dat het een schot hagel is. Linux, Apache en MySQL zijn niet mijn comfort zone maar ik ben gewend om een probleem te pinpointen, te begrijpen wat er precies gebeurt en dan de juiste oplossing te bepalen. Natuurlijk verhelpt een swapfile de symptomen maar het lost niet het probleem op, namelijk dat Apache en MySQL ofwel teveel geheugen gebruiken ofwel Linux het niet best doet als het gaat om geheugenmanagement.

Misschien juist omdat ik geen specialist ben op dit gebied wil ik goed begrijpen wat er speelt, wat het probleem is en waarom een bepaalde oplossing de beste is. Wat ik tot nu toe geleerd ben is dat een applicatie blijkbaar kan crashen vanwege onvoldoende beschikbaar geheugen zonder dit dat dit ergens gelogd wordt. Volgende is dan zorgen dat de applicatie niet langer teveel geheugen gebruikt. Pas als ik zeker weet dat de applicatie meer geheugen nodig heeft dan er in mijn server zit wil ik ofwel geheugen toevoegen (kostenimpact want zwaardere VM config) of een swap-file toevoegen.

Of zit er een probleem in mijn redenatie?

synoniem schreef op woensdag 21 oktober 2015 @ 23:10:
Op het moment dat je met een tijdelijke swapfile geen geheugenprobleem hebt, kan je met redelijke mate van zekerheid vaststellen dat het puur een geheugenruimte probleem is,

Op een Windows server weet ik welke performance counters ik moet monitoren om het geheugengebruik van een proces te monitoren. Op een Linux server zou ik verwachten dat ik precies datzelfde kan maar dan nog nauwkeuriger.

Niet 'met redelijke mate van zekerheid' vaststellen wat waarschijnlijk het probleem is.

Maar nogmaals, niemand heeft mij gevraagd naar de belasting van de server. Dit is dus een phpBB forum met een pakweg 10-15 nieuwe posts per dag. Dat zou op een server met 512 MB nog goed moeten draaien, laat staan een server met 768 MB. Toch?

[ Voor 26% gewijzigd door Jazzy op 22-10-2015 01:14 ]

Exchange en Office 365 specialist. Mijn blog.

donderdag 22 oktober 2015 08:25

Acties:

synoniem

Jazzy schreef op donderdag 22 oktober 2015 @ 01:10:
Dat het een schot hagel is. Linux, Apache en MySQL zijn niet mijn comfort zone maar ik ben gewend om een probleem te pinpointen, te begrijpen wat er precies gebeurt en dan de juiste oplossing te bepalen. Natuurlijk verhelpt een swapfile de symptomen maar het lost niet het probleem op, namelijk dat Apache en MySQL ofwel teveel geheugen gebruiken ofwel Linux het niet best doet als het gaat om geheugenmanagement.

Dat was je vraag niet, je vraag was waarom crashed MySQL. Linux heeft ook zo zijn tools en met bijvoorbeeld top (commandline) of taskmanager (gui) kun je precies en live zien welke processen hoeveel geheugen en cpu gebruiken. En zo zijn er nog wel wat tools.
Overigens gebruikt elke Windows versie ook een swapfile dus de vergelijking met deze setup en windows gaat dan al niet op.

Misschien juist omdat ik geen specialist ben op dit gebied wil ik goed begrijpen wat er speelt, wat het probleem is en waarom een bepaalde oplossing de beste is. Wat ik tot nu toe geleerd ben is dat een applicatie blijkbaar kan crashen vanwege onvoldoende beschikbaar geheugen zonder dit dat dit ergens gelogd wordt. Volgende is dan zorgen dat de applicatie niet langer teveel geheugen gebruikt. Pas als ik zeker weet dat de applicatie meer geheugen nodig heeft dan er in mijn server zit wil ik ofwel geheugen toevoegen (kostenimpact want zwaardere VM config) of een swap-file toevoegen.

Of zit er een probleem in mijn redenatie?

Ja loggen van fouten kost ook cpu en geheugenruimte en als het systeem dan de rest van het geheugen even kan swappen naar schijf komt het goed anders niet.

[...]
Op een Windows server weet ik welke performance counters ik moet monitoren om het geheugengebruik van een proces te monitoren. Op een Linux server zou ik verwachten dat ik precies datzelfde kan maar dan nog nauwkeuriger. Niet 'met redelijke mate van zekerheid' vaststellen wat waarschijnlijk het probleem is.

Nogmaals dat was je vraag niet en die tools zijn er onder Linux ook. Start bijvoorbeeld top op in een terminalvenster dan kun je live precies zien hoeveel geheugen apache2 en mysqld normaal gebruiken en hoeveel dat stijgt als je een backup probeert te maken.

Maar nogmaals, niemand heeft mij gevraagd naar de belasting van de server. Dit is dus een phpBB forum met een pakweg 10-15 nieuwe posts per dag. Dat zou op een server met 512 MB nog goed moeten draaien, laat staan een server met 768 MB. Toch?

Klopt, de belasting van de server is secundair al zou je 32 GB geheugen hebben en je krijgt deze melding dan is het nog steeds een geheugenprobleem.

Een server met 768 MB en een swapfile/partition van 1 GB moet dat wel kunnen hebben. Wordt het nog geen snelheidsmonster maar zal niet zo snel crashen.