Agrega Elasticsearch a un VPS que ya ejecuta nginx, PHP-FPM y MySQL. La primera importación de 400.000 fichas de producto se inicia el viernes por la noche. Dos horas más tarde, el sitio responde 502: el kernel eliminó php-fpm (no elasticsearch) porque la RAM se agotó y el caché del disco ya no compensaba.
Elasticsearch no es "una extensión de MySQL". Es un motor Java con máxima E/S y combinación que compite con su aplicación por los mismos recursos.
Montón, caché y la regla del 50%
Elasticsearch utiliza la JVM para el montón (estructuras en memoria) y se basa en la caché del sistema de archivos del sistema operativo para los segmentos de Lucene.
| Recurso | Rol | Error común |
|---|---|---|
| Montón JVM | Búfers de índice, consultas | Demasiado grande → GC se rompe, OOM |
| Caché de FS | Lectura de segmentos de disco | Competencia con aplicación + SO |
| CPU | Fusión, análisis | Saturación durante el volumen |
| Disco | Fusión de IOPS + translog | HDD saturado en reindexación |
Regla oficial de Elastic: montón ≈ 50% de RAM, máximo 32 GB. Más allá de eso, el recolector de basura JVM pierde eficiencia.
En un VPS de 4 a 8 GB compartido con la aplicación, ya estás en tensión estructural.
Indexación masiva sin agitar la máquina
1. Acelera el flujo
PUT _clúster/configuración
{
"persistente": {
"indexes.memory.index_buffer_size": "10%"
}
}
Reduzca refresh_interval a 30s o -1 durante la importación masiva, luego vuelva a colocar 1s en prod.
2. Tamaño del lote: comience con entre 1000 y 5000 documentos, mida la latencia y los rechazos.
3. Ventana horaria: índice por la noche si el VPS también atiende tráfico diurno.
4. Separación de roles: nodo ES dedicado u oferta administrada (Elastic Cloud, OpenSearch administrado en su nube).
Señales de advertencia antes de OOM
vmstat: sisi/so(swap) aumenta durante el volumen.docker statsohtop: montón ES estable pero RAM total al 100%.- La latencia de la aplicación se correlaciona con los picos "_bulk" en los registros de ES.
- Disco > 85%: fusión bloqueada, clúster amarillo/rojo.
Actúe antes de matar: haga una pausa masiva, aumente la RAM o migre ES.
La parte superior: la búsqueda de texto completo no siempre justifica Elasticsearch
Dimensionar la indexación también significa cuestionar si ES debería residir en la misma máquina.
Decide y avanza sin puntos ciegos
Calcule el presupuesto de RAM: montón de Elasticsearch más aplicación más sistema más margen del 20%. Si la aplicación es crítica en el mismo VPS, aísle Elasticsearch en un nodo dedicado u oferta administrada antes de la importación masiva. Pase grandes volúmenes a través de una cola con una aceleración masiva y un intervalo de actualización elevado temporalmente. Mida las estadísticas de vmstat y docker durante una prueba de importación, no solo el montón de JVM. Compare Elasticsearch administrado y alternativas ligeras (Meilisearch, Typesense) a través de nuestro comparador y el directorio si una simple búsqueda de texto completo es suficiente para el trabajo.
Preguntas frecuentes
¿Cuánta RAM asignar a Elasticsearch en un VPS de 8 GB?
Montón ≤ 50% de RAM, ≤ 32 GB absolutos. En 8 GB compartidos, suele ser preferible separar roles.
¿Por qué mi reindexación bloquea el servidor?
Masivo sin aceleración, fusión intensiva, caché de RAM privada: OOM Killer en la aplicación o ES.
¿Deberíamos indexar sincrónicamente desde la aplicación?
No para grandes volúmenes: cola + trabajadores en masa con el intervalo de actualización ajustado.
¿Vale la pena el coste de Managed Elasticsearch?
Sí, si se trata de indexación crítica y equipo pequeño; de lo contrario, Meilisearch o Typesense en VPS económico.
Antes de indexar por la noche, una pregunta: ¿quién paga la RAM si el volumen disminuye: Elasticsearch o su tienda en línea?