Je voegt Elasticsearch toe aan een VPS waar al nginx, PHP-FPM en MySQL op draait. Op vrijdagavond wordt de eerste import van 400.000 productbladen gelanceerd. Twee uur later antwoordt de site 502: de kernel heeft php-fpm gedood (niet elasticsearch) omdat het RAM-geheugen uitgeput was en de schijfcache niet langer compenseerde.
Elasticsearch is geen “verlengstuk van MySQL”. Het is een Java-engine met piek-I/O en merge die met uw applicatie concurreert om dezelfde bronnen.
Heap, cache en de 50%-regel
Elasticsearch gebruikt de JVM voor de heap (in-memory-structuren) en vertrouwt op de bestandssysteemcache van het besturingssysteem voor Lucene-segmenten.
| Bron | Rol | Veel voorkomende fout |
|---|---|---|
| Heap-JVM | Indexbuffers, query's | Te groot → GC breekt, OOM |
| FS-cache | Schijfsegmenten lezen | Concurrentie met app + besturingssysteem |
| CPU | Samenvoegen, analyseren | Verzadiging tijdens bulk |
| Schijf | IOPS samenvoegen + translog | HDD verzadigd bij herindexering |
Officiële elastische regel: heap ≈ 50% RAM, max 32 GB. Daarnaast verliest de JVM-garbagecollector zijn efficiëntie.
Op een VPS van 4–8 GB gedeeld met de app zit je al in structurele spanning.
Bulkindexering zonder de machine te schudden
1. Beperk de stroom
PUT _cluster/instellingen
{
"aanhoudend": {
"indexes.memory.index_buffer_size": "10%"
}
}
Reduceer refresh_interval naar 30s of -1 tijdens massa-import en plaats 1s terug in prod.
2. Batchgrootte — begin met ongeveer 1000–5000 documenten, meet de latentie en afwijzingen.
3. Tijdvenster — index 's nachts als de VPS ook overdag verkeer bedient.
4. Scheiding van rollen — speciaal ES-knooppunt of beheerd aanbod (Elastic Cloud, OpenSearch beheerd in uw cloud).
Waarschuwingssignalen vóór OOM
vmstat: alssi/so(swap) stijgt tijdens bulk.docker statsofhtop: heap ES stabiel maar totaal RAM op 100%.- Applicatielatentie gecorreleerd met
_bulk-pieken in ES-logboeken. - Schijf > 85% — samenvoegen geblokkeerd, cluster geel/rood.
Handel vóór de moord: pauzeer bulk, verhoog het RAM-geheugen of migreer ES.
De bovenkant: zoeken in volledige tekst rechtvaardigt niet altijd Elasticsearch
Het dimensioneren van de indexering betekent ook dat je je moet afvragen of ES op dezelfde machine moet leven.
Beslis en ga vooruit zonder blinde vlek
Bereken het RAM-budget: Elasticsearch-heap plus applicatie plus systeem plus 20% marge. Als de applicatie cruciaal is op dezelfde VPS, isoleer Elasticsearch dan op een speciaal knooppunt of beheerd aanbod voordat u bulksgewijs importeert. Geef grote volumes door een wachtrij met bulk-throttle en refresh_interval tijdelijk verhoogd. Meet vmstat- en docker-statistieken tijdens een importtest, niet alleen de JVM-heap. Vergelijk beheerde Elasticsearch en lichtgewicht alternatieven (Meilisearch, Typesense) via onze vergelijker en de overzicht als eenvoudig zoeken in de volledige tekst voldoende is voor de taak.
Veelgestelde vragen
Hoeveel RAM moet ik toewijzen aan Elasticsearch op een VPS van 8 GB?
Heap ≤ 50% RAM, ≤ 32 GB absoluut. Op 8 GB gedeeld heeft het scheiden van rollen vaak de voorkeur.
Waarom crasht mijn herindexering van de server?
Bulk zonder gas geven, intensief samenvoegen, privé RAM-cache - OOM-killer in de app of ES.
Moeten we synchroon indexeren vanuit de applicatie?
Nee voor grote volumes: wachtrij + werknemers in bulk met verversingsinterval aangepast.
Is Managed Elasticsearch de kosten waard?
Ja bij kritische indexering en een klein team; anders Meilisearch of Typesense op budget VPS.
Voordat u 's nachts gaat indexeren, een vraag: wie betaalt voor RAM als het grootste deel wegvalt - Elasticsearch of uw online winkel?