Vous ajoutez Elasticsearch à un VPS qui fait déjà tourner nginx, PHP-FPM et MySQL. L'import initial de 400 000 fiches produit se lance un vendredi soir. Deux heures plus tard, le site répond 502 : le kernel a tué php-fpm — pas elasticsearch — parce que la RAM était épuisée et que le cache disque ne compensait plus.
Elasticsearch n'est pas « une extension de MySQL ». C'est un moteur Java avec des pics d'I/O et de merge qui rivalise avec votre application pour les mêmes ressources.
Heap, cache et la règle des 50 %
Elasticsearch utilise la JVM pour le heap (structures in-memory) et s'appuie sur le filesystem cache de l'OS pour les segments Lucene.
| Ressource | Rôle | Erreur fréquente |
|---|---|---|
| Heap JVM | Index buffers, requêtes | Trop grand → GC pauses, OOM |
| FS cache | Lecture segments disque | Compétition avec app + OS |
| CPU | Merge, analyse | Saturation pendant bulk |
| Disque | IOPS merge + translog | HDD saturé en réindex |
Règle officielle Elastic : heap ≈ 50 % de la RAM, max 32 Go. Au-delà, le garbage collector JVM perd en efficacité.
Sur un VPS 4–8 Go partagé avec l'app, vous êtes déjà en tension structurelle.
Indexation bulk sans faire trembler la machine
1. Throttle le débit
PUT _cluster/settings
{
"persistent": {
"indices.memory.index_buffer_size": "10%"
}
}
Réduisez refresh_interval à 30s ou -1 pendant l'import massif, puis remettez 1s en prod.
2. Taille de batch — commencez autour de 1000–5000 docs, mesurez latence et rejets.
3. Fenêtre horaire — indexez la nuit si le VPS sert aussi le trafic jour.
4. Séparation des rôles — nœud ES dédié ou offre managée (Elastic Cloud, OpenSearch managé chez votre cloud).
Signaux d'alerte avant OOM
vmstat: sisi/so(swap) monte pendant bulk.docker statsouhtop: heap ES stable mais RAM totale à 100 %.- Latence application corrélée aux pics
_bulkdans les logs ES. - Disque > 85 % — merge bloqué, cluster yellow/red.
Agissez avant le kill : pause bulk, augmentez RAM, ou migrez ES.
Le sommet : la recherche full-text ne justifie pas toujours Elasticsearch
Dimensionner l'indexation, c'est aussi questionner si ES doit vivre sur la même machine.
Décider et avancer sans angle mort
Calculez le budget RAM : heap Elasticsearch plus application plus système plus marge de 20 %. Si l'application est critique sur le même VPS, isolez Elasticsearch sur un nœud dédié ou une offre managée avant l'import massif. Passez les gros volumes par une file d'attente avec bulk throttle et refresh_interval temporairement relevé. Mesurez vmstat et docker stats pendant un import test — pas seulement le heap JVM. Comparez Elasticsearch managé et alternatives légères (Meilisearch, Typesense) via notre comparateur et l'annuaire si la recherche full-text simple suffit au métier.
Questions fréquentes
Combien de RAM allouer à Elasticsearch sur un VPS 8 Go ?
Heap ≤ 50 % RAM, ≤ 32 Go absolus. Sur 8 Go partagés, séparer les rôles est souvent préférable.
Pourquoi ma réindexation fait planter le serveur ?
Bulk sans throttle, merge intensif, cache privé de RAM — OOM killer sur l'app ou ES.
Faut-il indexer en synchrone depuis l'application ?
Non pour gros volumes — queue + workers bulk avec refresh_interval ajusté.
Managed Elasticsearch vaut-il le coût ?
Oui si indexation critique et petite équipe ; sinon Meilisearch ou Typesense sur VPS budget.
Avant d'indexer la nuit, une question : qui paie en RAM si le bulk dérape — Elasticsearch ou votre boutique en ligne ?