Hoeveel RAM heeft WordPress nodig?
WordPress zelf heeft weinig geheugen nodig en de officiële vereisten noemen geen RAM-hoeveelheid. Voor een kleine site is 1-2 GB RAM meestal een goed beginpunt (een vuistregel die per site verschilt). Webshops, veel plug-ins en veel verkeer kunnen de behoefte naar 4 GB of meer duwen.
Wat je echt nodig hebt, hangt af van het soort site: de plug-ins, het verkeer, de omvang van de database en of caching aanstaat. Dit artikel behandelt de officiële cijfers, wat geheugen opslokt en hoe je merkt dat het niet genoeg is.
Wat zeggen de officiële vereisten?
De pagina met hostingvereisten op WordPress.org (een officiële aanbeveling) vraagt om PHP 8.3 of nieuwer, MariaDB 10.11 of MySQL 8.0 of nieuwer en ondersteuning voor HTTPS. Als webserver wordt Apache of Nginx aanbevolen. De pagina geeft geen cijfer voor RAM. Oudere versies zoals PHP 7.4 en MySQL 5.5.5 draaien nog wel, maar de pagina merkt op dat ze het einde van hun levensduur hebben bereikt en beveiligingsrisico's hebben. Kies bij een nieuwe installatie de aanbevolen versies.
De enige officiële geheugencijfers zijn de limieten die PHP aan WordPress geeft. Bij een installatie met één site is de standaardwaarde van WP_MEMORY_LIMIT 40 MB, en bij multisite 64 MB. Het beheergedeelte gebruikt WP_MAX_MEMORY_LIMIT, en de kern van WordPress probeert die standaard te verhogen naar 256 MB. Dit zijn plafonds voor één PHP-verzoek, niet het totale RAM van de server. De waarden die voor jouw site gelden, controleer je onder Tools > Site Health > Info: de PHP-geheugenlimiet staat in het gedeelte Server, terwijl WP_MEMORY_LIMIT en WP_MAX_MEMORY_LIMIT in het gedeelte WordPress Constants staan.
Wat gebruikt het RAM echt?
- PHP-processen. Elk gelijktijdig verzoek draait een PHP-proces. In PHP-FPM beperkt
pm.max_childrenhoeveel er tegelijk kunnen draaien (zie de PHP-handleiding). Afhankelijk van de plug-ins kan één proces tientallen tot honderden megabytes gebruiken. Dat is een algemene waarneming en het verschilt per site. - De database. MariaDB of MySQL houdt vaak gelezen gegevens in het geheugen. Grote sites met veel plug-ins willen meer.
- De cache van het besturingssysteem. Linux gebruikt vrij geheugen als schijfcache. Weinig vrij geheugen in de uitvoer van
free -his geen probleem. Kijk liever naar de kolom available. - Cachelagen. Een objectcache (zoals Redis) vermindert databasequery's, maar gebruikt zelf ook geheugen.
Een eenvoudig voorbeeld. Zet je op een server met 2 GB RAM ongeveer 1 GB opzij voor het besturingssysteem en de database, dan blijft er 1 GB over voor PHP. Gebruikt één PHP-proces gemiddeld 100 MB, dan is het zinvol pm.max_children rond 10 te houden. Deze getallen laten alleen zien hoe de berekening werkt. Je eigen metingen kunnen anders uitvallen.
Beginmaat per type site
Deze waarden zijn vuistregels. Ze verschillen per plug-ins en verkeer en zijn geen vaste belofte.
| Type site | Begin-RAM | Opmerking |
|---|---|---|
| Kleine blog of visitekaartjessite, weinig plug-ins | 1-2 GB | Zet paginacaching aan |
| Bedrijfssite met veel formulieren en afbeeldingen | 2-4 GB | Verklein je afbeeldingen |
| Paginabuilder, ledensite, veel plug-ins | 4 GB | Meer pagina's die niet gecachet kunnen worden |
| Webshop (WooCommerce) | 2-4 GB, meer naarmate hij groeit | Winkelwagen- en afrekenpagina's kunnen niet worden gecachet |
Bouw je een webshop, lees dan ook ons artikel "Een server kiezen voor WooCommerce".
Wat zie je als het RAM opraakt?
- De site geeft af en toe een 502- of 503-fout. PHP-FPM of de webserver kan niet antwoorden.
- Er verschijnt de melding "Error establishing a database connection". De database is mogelijk gestopt omdat het geheugen op was.
- Het beheergedeelte wordt erg traag en pluginupdates of het uploaden van afbeeldingen blijven halverwege hangen.
Om dit te bevestigen verbind je met de server en voer je deze opdrachten uit:
free -h
sudo journalctl -k | grep -i -E "out of memory|oom-kill"
De tweede opdracht toont de gebeurtenissen waarbij de kernel een programma stopte omdat het geheugen op was. Als hij regels toont, is het RAM niet genoeg. Druk in top op Shift+M om de processen te zien die het meeste geheugen gebruiken.
Wat je kunt proberen voor je opschaalt
- Zet een paginacache op, als plug-in of aan de serverkant. Een pagina die uit de cache komt, laat noch PHP noch de database draaien.
- Verwijder plug-ins die je niet gebruikt. Elke actieve plug-in laadt zijn code bij elk verzoek.
- Stem
pm.max_childrenin PHP-FPM af op je geheugen. Grofweg deel je het geheugen dat je aan PHP kunt geven door het gemiddelde geheugen van één PHP-proces. Een te hoge waarde eet geheugen op onder belasting. - Een kleine swapruimte voorkomt dat de server crasht bij korte pieken. Maar swap staat op schijf en is traag, dus het is geen vervanging voor RAM.
Heb je dit allemaal geprobeerd en loopt het geheugen nog steeds vol, dan is het tijd om op te schalen. Meet eerst: komt het probleem voor tijdens piekuren, of de hele dag? Als algemene drempel kun je opschalen overwegen als het available geheugen op piekuren vaak onder 10-15 procent van het totale RAM zakt, of als swap constant in gebruik is. Dat is geen harde regel, alleen een beginpunt.
Opschalen vanuit het paneel
In het Seturack-paneel schaal je de server op met de schuif op het tabblad Grootte. Na betaling herstart de server eenmalig vanzelf en blijven je IP-adres en gegevens hetzelfde. Daarom is beginnen met een kleine maat een veilige route. Een server met WordPress voorgeïnstalleerd staat in ongeveer 3,5 tot 4 minuten klaar. Bekijk de pagina WordPress-server.
Reacties0
Nog geen reacties
Deel als eerste uw gedachten.
Meld u aan of registreer u om een reactie te plaatsen.