unix - single - vm.max_map_count y mmapfs
elasticsearch single node (1)
¿Cuáles son los pros y los contras de aumentar vm.max_map_count de 64k a 256k?
¿Implica vm.max_map_count = 65530 -> 64k direcciones * 64kb de tamaño de página = hasta 4GB de datos pueden ser referenciados por el proceso?
Y si supero los 4 GB, el espacio direccionable debido al límite de vm.max_map_count, ¿el sistema operativo tendrá que abrir algunos de los datos indexados más antiguos?
Tal vez mi comprensión anterior no es correcta ya que el caché FS puede ser bastante grande
¿Cómo resulta este límite en OOM?
Publiqué una pregunta similar sobre el contexto de elasticsearch en https://discuss.elastic.co/t/mmapfs-and-impact-of-vm-max-map-count/55568
Respondiendo a mi propia pregunta basada en una mayor excavación y respuesta de Uwe Schindler - Lucene PMC
El tamaño de página no tiene nada que ver con max_map_count. Es el número de asignaciones que se asignan. Los mapas MMapDirectory de Lucene en porciones de hasta 1 GiB. El número de asignaciones depende de la cantidad de segmentos (cantidad de archivos en el directorio de índice) y su tamaño. Un índice típico con como 40 archivos en el directorio de índice, todos ellos más pequeños que 1 GiB necesita 40 asignaciones. Si el índice es más grande, tiene 40 archivos y la mayoría de los segmentos tienen como 20 Gigabytes, entonces podría tomar hasta 800 asignaciones.
El motivo por el cual la gente de Elasticsearch recomienda aumentar max_map_count es debido a la estructura de sus clientes. La mayoría de los usuarios de Logstash tienen nubes Elasticsearch con un tamaño de 10.000 índices, posiblemente muy grandes, por lo que el número de mapas podría ser un factor limitante.
Sugeriría que no cambie la configuración predeterminada, a menos que obtenga IOExceptions sobre "error en el mapa" (tenga en cuenta que no dará como resultado OOM con versiones recientes de Lucene ya que esto se maneja internamente).
La búsqueda del sistema operativo no tiene nada que ver con el recuento de archivos asignados. Max_map_count es solo un límite de cuántas asignaciones se pueden usar en total. Una asignación necesita un fragmento de hasta 1 GiB que está mapeado. La paginación en el sistema operativo ocurre en un nivel mucho más bajo, intercambiará cualquier parte de acuerdo con el tamaño de la página de esos fragmentos de forma independiente: trozo! = Tamaño de la página
Resumen: corrígeme si me equivoco, a diferencia de lo que sugiere la documentación. No creas que se requiere aumentar max_map_count en todos los escenarios
ES 2.x - En el modo predeterminado (híbrido nio + mmap) FS solo los archivos .dvd y .tim (tal vez el punto también) están mapeados y eso permitiría aproximadamente 30000 fragmentos por nodo.
ES 5.x - hay un límite en el segmento, por lo que aunque se mueva a mmapfs por defecto, el valor predeterminado de 64k puede funcionar bien.
Esto podría ser útil si planea usar mmapfs y tener> 1000 fragmentos por nodo. (Personalmente, veo muchos problemas adicionales con altos fragmentos / nodos)
Tienda mmapfs: solo cuando la tienda es mmapfs y cada nodo almacena> 65000 archivos de segmento (o más de 1000 fragmentos) entrará este límite. Prefiero agregar más nodos que tener una cantidad tan enorme de fragmentos por nodo en mmapfs