Desactivar swap en el sistema.
swapoff -a # Opcion 2: sysctl -w vm.swappiness=1
Es mejor siempre desactivar la swap completamente, ya que en determinados momentos, aunque tengamos el swappiness a 1 o 0, la swap puede ser utilizada en caso de emergencia. En cuanto al valor de swappiness, se debe evitar el 0 ya que puede provocar en algunos casos OOM-killer.
Memoria RAM de los procesos de ElasticSearch.
Variables que rigen el uso de memoria RAM de ElasticSearch, se pueden configurar en el mismo ejecutable elasticsearch.
ES_HEAP_SIZE=3g # Total de la memoria RAM utilizada por ES. (//ES_HEAP_SIZE=3g// = //ES_MIN_MEM=3g// y //ES_MAX_MEM=3g//). # ES_MIN_MEM # Mínimo de memoria a utilizar por ES (256m por defecto). # ES_MAX_MEM # Máximo tamaño de memoria RAM utilizada por ES (1g por defecto). # Equivalente al arrancar el servicio. ./bin/elasticsearch -Xmx3g -Xms3g
No se deben utilizar servidores de más de 64Gb de memoria RAM, tampoco se recomienda de más de 30-32 Gb para configurar el ES_HEAP_SIZE. A partir de 32 Gb, java no puede comprimir oops (Leer), por lo que importa poco que se tenga un servidor con más de un 2T de memoria que estos nunca serán usados. Recordar que es posible ejecutar varias instancias si se usan diferentes ficheros de configuración, nombres y puertos.
Activar mlockall en ElasticSearch: /etc/elasticsearch/elasticsearch.yml
bootstrap.mlockall: true
No se debe usar toda la memoria ram del servidor para ElasticSearch, ya que Lucene necesita también memoria que no está definida dentro de lo que se reserva con “ES_HEAP_SIZE”. Lucene está diseñado para aprovechar el sistema operativo subyacente para las estructuras de datos de almacenamiento en memoria caché. Los Segmentos de datos de Lucene son inmutables (no cambian nunca) y se almacenan en archivos individuales, esto los hace buenos candidatos para que el SO los mantenga en memoria ram para su rápido acceso.
Por tanto, lo recomendado es darle la mitad a ES_HEAP_SIZE y la otra mitad para el sistema operativo / Lucene, si Lucene no tiene memoria el rendimiento de búsquedas de texto completo puede perjudicarse mucho. Lucene nunca dejará de llenar la memoria que tenga disponible, por lo que no hay que preocuparse de que pueda quedar ram en desuso
Cache del campo data. (Field data cache)
La cache del campo data (por defecto ilimitada), es usada cuando se realiza un facetado o se ordena una salida, cargando todos los valores de los campos en memoria. Por tanto su configuración tiene impacto sobre esas dos actividades, en mayor medida cuando se utilizan índices grandes.
Establecer un limite del 25% de ES_HEAP_SIZE par la cache de campos.
indices.fielddata.cache.size: 25% # Definir un valor fijo. indices.fielddata.cache.size: 12GB
Monitorización del campo data: https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html
NOTA: Al crear un campo se puede definir.
Recomendaciones típicas.
Si se usan discos duros mecánicos convencionales (no SSD), se debe limitar el numero de hilos que deben acceder al disco de forma concurrente, el valor de hilos es igual al valor de “max_thread_count + 2”.
Por defecto el valor es “Math.max(1, Math.min(3, Runtime.getRuntime().availableProcessors() / 2))”, el cual debe ser para discos SSD la opción recomendada, pero si se utilizan discos no SSD, la recomendación es utilizar el valor 1.
index.merge.scheduler.max_thread_count: 1
Para tener un menor número de operaciones de entrada salida y mejores tasas de indexación, se puede incrementar el valor de index.translog.flush_threshold_size de 200 a 1GB. De esta forma el translog (donde se guardan todas las transacciones de indexación o borrado) será limpiado cuando segmentos de datos más grandes han sido creados dentro de él. Esto provoca operaciones en el disco menos frecuentes a si se trataran con segmentos de menor tamaño.
Aumentar el número de lineas que dicho translog (uno por fragmento) puede contener antes de ser limpiado, por defecto es de 5000 pero se puede cambiar por ejemplo a 30000 para escribir menos frecuentemente en disco.
index.translog.flush_threshold_ops: 50000
Es factible utilizar varios discos duros dentro de una misma instancia de ES, normalmente se usa para los datos (data) de esta forma se consigue el mismo efecto que un RAID0 mejorando mucho el rendimiento de I/O. Otra recomendación es también separar los logs, plugins etc del disco de datos, aunque no supondría un aumento del rendimiento destacable.
# Especificar diferentes directorios / puntos de montaje para almacenar los datos. path.data: /path/to/data1,/path/to/data2 # Ruta a los ficheros de logs. path.logs: /path/to/logs # Ruta a los plugins. path.plugins: /path/to/plugins
Por norma el número de microprocesadores / núcleos es detectado por ElasticSearch automáticamente, pero puede ser útil configurarlo a medida cuando se tienen varias instancias de ElasticSearch en una misma máquina (baremetal). Las “threads pools” comentadas anteriormente se basan en ese valor para configurar sus cantidad de hilos para cada tarea. para un entornos con ElasticSearch es mejor elegir entre máquinas con muchos cores que no con muchas CPUs.
Si se tienen 8 núcleos y dos instancias de ES, se pueden utilizar “processor:4” en cada instancia.
La opción “queue_size” permite controlar el tamaño de la cola de peticiones pendientes que están pendientes de ser recogidas por algún hilo. De forma predeterminada tiene el valor -1, que indica sin límite. Cuando llega una petición y la cola está llena, la petición es cancelada.
Especificar el número de hilos (por defecto cores x 5) / Delimitar el tamaño de las colas por hilo.
curl -XPUT 'localhost:9200/_cluster/settings' -d '{ "transient": { "threadpool.index.size":40 } }' curl -XPUT 'localhost:9200/_cluster/settings' -d '{ "transient": { "threadpool.index.queue_size":2000 } }' curl -XGET 'localhost:9200/_cluster/settings'
Si se van a realizar búsquedas que usan rangos de tiempo amplios como meses y años, se recomienda aumentar también la cola de búsquedas (1000 por defecto).
curl -XPUT 'localhost:9200/_cluster/settings' -d '{ "transient": { ""threadpool.search.queue_size":5000 } }'
Típico error por un tamaño de cola demasiado pequeña a la hora de indexar.
Caused by: org.elasticsearch.ElasticsearchException: Unable to execute index operation on cluster Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 1000) on org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1@263666cd at org.elasticsearch.common.util.concurrent.EsAbortPolicy.rejectedExecution(EsAbortPolicy.java:62) ~[elasticsearch-1.0.0.jar:na]
Configurar hilos (Thread pools) / colas.
Lo que se denomina como “thread pools” viene a ser una colección de hilos en estado de espera que ejecutan las tareas almacenadas en una cola de tareas. La comunicación entre esos diferentes grupos es algo común, por ejemplo los hilos encargados de recibir información por red se comunican con los encargados de escribir dicha información en disco. Los thread pools son utilizados debido a que la creación de nuevos hilos según son necesarios es computacionalmente más costoso.
Cuando una tarea es recibida y encolada, se le asigna un hilo para que empiece a trabajar con ella, si los hilos están ocupados con diferentes tareas, las nuevas tareas se siguen encolando hasta que hilos libres puedan empezar a trabajar con ellas. ElasticSearch tiene varios grupos de hilos (thread Pools) para configurar en base al consumo de memoria dentro de un nodo. Muchas de esos grupos de hilos tienen asociadas colas de tareas.
Es importante asignar el número de hilos / límites de las colas acorde a las necesidades y recursos disponibles. El número de hilos nunca debe ser superior al número de núcleos del procesador. La configuración por defecto del grupo de subprocesos en Elasticsearch es muy sensibles. Para todos los conjuntos de subprocesos (excepto search), el número de hilos se establece en relación al número de núcleos de CPU. Si se tiene ocho núcleos, solo se pueden ejecutar ocho hilos simultáneamente.
NOTA: Subir los valores dentro de la configuración de los hilos no tiene sentido, un hilo por cada core es lo correcto si se quieren paralelizar tareas.
Tipos de Thread Pools en ES.
Las Thread pools más importantes.
Establecer temporalmente y en todos los nodos del clúster la cantidad de hilos a ejecutar.
curl -XPUT 'localhost:9200/_cluster/settings' -d '{ "transient": { "threadpool.index.size":24 } }'
Leer: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html
Indexación de documentos por lotes.
Si se utiliza la indexación por lotes de forma continua, como por ejemplo al tratar con logs, es recomendable subir el valor de la cola para no perder datos y evitar los errores de “RemoteTransportException”. En ES cada Bulk request contiene un item por shard, por lo que el número debe ser mayor que el número de peticiones concurrentes permitido.
# Numero de peticiones que pueden ser encoladas cuando no hay hilos disponibles para su tratamiento. threadpool.bulk.queue_size: 2000
Error que indica que se debe subir el valor.
RemoteTransportException[[<Bantam>][inet[/192.168.76.1:9300]][bulk/shard]]; nested: EsRejectedExecutionException[rejected execution (queue capacity 10) on org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1@13fe9be];
Por defecto, se reserva / prioriza el 90% de la memoria RAM definida en ES para funciones de búsqueda. Si se debe tener más capacidad de indexado o bien se prefiere tener más igualado el rendimiento entre indexación (40%) y búsqueda (60%), se puede configurar la siguiente directiva.
indices.memory.index_buffer_size: 40%
ElasticSearch tiene varias colas asociadas a las que se puede ajustar su tamaño para evitar que los hilos empiecen a descartar peticiones (escritura, búsquedas, etc) bajo cargas altas. Con el comando siguiente se pueden visualizar estadísticas de uso de las colas y ver si algo falla. Aquí podrá ver los distintos valores que se pueden configurar para ajustar los hilos y colas a necesidades.
host ip bulk.active bulk.queue bulk.rejected index.active index.queue index.rejected search.active search.queue search.rejected 10.0.207.18 10.0.207.18 0 0 0 0 0 0 10 23825 0 10.0.107.64 10.0.107.64 3 0 0 0 0 0 10 24972 0 10.0.127.92 10.0.127.92 0 0 0 0 0 0 0 0 0 14.0.207.90 14.0.207.90 0 0 0 0 0 0 10 24968 0 109.0.207.117 109.0.207.117 0 0 0 0 0 0 10 24539 0 10.40.207.91 10.40.207.91 0 0 0 0 0 0 0 0 0
Cuando Kibana muestra los errores de “Courier Fetch: XX of XX shards failed”, la cola referente a las búsquedas es la que se debe configurar (por defecto 1000). De esta manera se aplicaría el valor en caliente al nodo.
curl -XPUT http://localhost/_cluster/settings -d '{ "persistent" : { "threadpool.search.queue_size" : 50000 } }'
En el fichero /etc/elasticsearch/elasticsearch.yml puede ser configurada de la siguiente manera.
## Threadpool Settings ## ## Search pool threadpool.search.type: fixed threadpool.search.size: 10 threadpool.search.queue_size: 70000 # Bulk pool threadpool.bulk.type: fixed threadpool.bulk.size: 6 threadpool.bulk.queue_size: 100 ## Index pool threadpool.index.type: fixed threadpool.index.size: 6 threadpool.index.queue_size: 200
Limites de memoria y Ficheros abiertos del sistema operativo.
El masivo uso de descriptores de ficheros abiertos se debe en gran parte al uso de búsquedas lucene y sockets a causa de la interconexión entre nodos y clientes http produce muchos sockets.
Limitar número de ficheros abiertos por un usuario y quitar el límite al máximo de memoria asignada para un usuario. Para ello se debe editar el fichero /etc/security/limits.conf o bien ejecutar los comandos “ulimit” siguientes.
elasticsearch - nofile 100000 elasticsearch - memlock unlimited # Quitar límites al bloqueo de memoria por linea de comandos. # ulimit -l unlimited # ulimit -SHn 10000
Si se desea que el limite de ficheros abiertos supere a lo establecido por el kernel, se debe modificar también “sysctl fs.file-max”.
Lectura recomendada: configurar_limite_de_ficheros_abiertos
Para ejecutar ElasticSearch después de haber establecido por linea de comandos los parámetros de “ulimit”, se debe entrar desde esa misma shell a la cuenta del usuario que ejecutará ElasticSearch (comando su). Lo recomendable por tanto es definir los valores en ficheros de configuración.
pam-limits: Puede ser que se deba realizar un paso adicional si la configuración de los descriptores de ficheros no tiene efecto. Para ello se debe editar /etc/pam.d/common-session y agregar la siguiente linea.
session required pam_limits.so
Memoria Virtual
Elasticsearch utiliza un directorio mmapfs / niofs híbrido para almacenar sus índices. Los límites del sistema operativo por defecto en los recuentos de mmap son demasiado bajos y provoca excepciones de memoria. para aumentarlo se puede utilizar el siguiente comando o bien para el fichero de configuración /etc/sysctl.conf.
#Consultar el valor por defecto. sysctl vm.max_map_count vm.max_map_count = 65530 # Nuevo valor. sysctl -w vm.max_map_count = 262144
Para establecer de manera permanente este valor, actualice la configuración en /etc/sysctl.conf.
vm.max_map_count = 262144
Configurar ElasticSearch. Es recomendable usar los parámetros configurados anteriormente también en las variables de entorno de ES.
ES_HEAP_SIZE=3g # Memoria RAM total que usará ElasticSearch MAX_OPEN_FILES=100000 # Definido previamente con ulimit. MAX_LOCKED_MEMORY=unlimited # Definido previamente con ulimit. LimitMEMLOCK=infinity # Variable MAX_LOCKED_MEMORY definida como unlimited y bootstrap.mlockall: true # Comprobar que /tmp no esté montado como "noexec" o bien se crea /tmp/elasticsearch. # WORK_DIR=/tmp/elasticsearch
Comprobar configuración de descriptores de ficheros y mlockall. Ejecutar ElasticSearch con la siguiente opción y comprobar posteriormente la configuración de descriptores de ficheros.
./elasticsearch -Des.max-open-files curl localhost:9200/_nodes/process?pretty
{ "cluster_name" : "escluster", "nodes" : { "Fa2cY8zIQw-uGhNrAnauEw" : { "name" : "busi arch", "transport_address" : "inet[/192.1.178.55:9300]", "host" : "busiarch", "ip" : "192.168.178.50", "version" : "1.5.2", "build" : "62ff986", "http_address" : "inet[/192.168.1.55:9200]", "process" : { "refresh_interval_in_millis" : 1000, "id" : 6098, "max_file_descriptors" : 10000, "mlockall" : true } } } }
Los nodos “clientes” con usados como batidores de carga, son también parte del clúster y pueden redirigir operaciones exactamente al nodo que contiene los datos pertinentes sin tener que consultar todos o parte de los nodos. Este tipo de nodos no almacena datos y por lo tanto no realiza operaciones de gestión de clúster.
La otra ventaja de los nodos clientes es que se encargan de las operaciones de dispersión / recopilación (como las búsquedas), aliviando por tanto de esas tareas a los nodos de datos (analizar peticiones HTTP, buscar nodos, ordenar resultados, etc.)
Configurar Nodos cliente: Para ello se deben configurar elasticsearch.yml
http.enabled: true
master: false
data: false
discovery:
zen:
ping:
multicast:
enabled: false
unicast:
hosts: 192.168.1.1:9300, 192.168.1.2:9300, 192.168.1.3:9300
Configurar Nodos de datos (no reciben peticiones http).
http.enabled: false
Configurar nodos maestro dedicados.
Estos tipos de nodos tienen muy bajo consumo de recursos ya que solo se dedican a la administración del clúster y no reciben tareas de indexación o búsqueda, se recomienda tener un mínimo de tres nodos dedicados en infraestructuras en producción.
node.data: false node.master: true
Una buena configuración en cuanto a recuperaciones del clúster por motivos de mantenimiento, cortes de red, etc es en la mayoría de casos algo crucial. Una configuración de recuperación puede ahorrar mucho movimiento de fragmentos y por tanto saturación de la red. Cuando una parte del clúster no espera a la otra para empezar a reordenar los datos, es cuando se originan los porblemas, ya que cuando los otros nodos reaparecen, se debe volver a reasignar todo.
Para solucionar esto se debe dar un límite “duro” para que no empiece una recuperación de datos hasta que X número de nodos (data o master) estén presentes. En conjunto con un limite de tiempo nos otorga cierta estabilidad y procesos de recuperación de segundos y no de horas.
# El cluster no opera hasta que hay por lo menos 8 nodos activos. gateway.recover_after_nodes: 8 # Comienza la recuperación después de 5 minutos o cuando 10 nodos estén en el clúster, lo que primero ocurra. gateway.expected_nodes: 10 gateway.recover_after_time: 5m
NOTA: Estos parámetros se deben configurar en el fichero de configuración “elasticsearch.yml”, no se puede cambiar en caliente son las opciones del clúster.
Empezar a realocar shards únicamente si un nodo cae y no vuelve en 5 Minutos.
curl -k -XPUT http://XXX/_all/_settings -d '{ "settings" : { "index.unassigned.node_left.delayed_timeout": "6m" } }'
Desde Kopf se puede detener globalmente también la realocación pulsando sobre el candado. Es muy recomendable de usar si se quieren reiniciar / actualizar nodos. Leer.
En producción, multicast (opción predeterminada) debe ser desactivado para que solo se permita la comunicación mediante unicast. De esta manera se evita el riesgo de que nodos no pertenecientes al cluster se unan tras recibir un ping multicast.
Para deshabilitar multicast y dejar unicamente unicast como medio de comunicación, no es necesario definir todas las direcciones IPs en cada nodo. Vale con configurar las direcciones de los nodos maestros para que puedan obtener toda la información pertinente.
# Se debe asegurar que no está permitido ya que puede funcionar en paralelo con unicast. discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
Asignación de fragmentos (shards allocation).
La asignación de fragmentos es el proceso por el cual se asignan los diferentes shards que forman un índice a los nodos del cluster. Esto sucede al inicio de una recuperacion del cluster tras un reinicio o desconexión de nodos, en la asignación de una réplica o al realizar un rebalanceo de fragmentos.
La directiva “cluster.routing.allocation.cluster_concurrent_rebalance” determina el número de asignaciones concurrentes que se pueden llevar a cabo, esta se debe ajustar dependiendo del hardware que se disponga.
Por defecto el valor es 2, es decir, solo 2 fragmentos pueden moverse al mismo tiempo, un valor alto puede afectar a la velocidad de indexado negativamente.
La directiva “cluster.routing.allocation.disk.threshold_enabled” cuando tiene el valor true, toma en cuenta el espacio disponible en el nodo a la hora de asignar shards.
cluster.routing.allocation.disk.threshold_enabled:true # Si el 90% del disco está ocupado se detienen la asignacion para ese nodo. cluster.routing.allocation.disk.watermark.low: 90% # Si el 95% del disco está lleno ES empezará a sacar fragmentos de ese nodo para reasignarlos. cluster.routing.allocation.disk.watermark.high: 95%
Propiedades de recuperación.
Lo mejor es probar con varios valores en base al hardware que se tenga, dejar a punto esta configuración requiere realizar varias pruebas e ir adaptando los valores.
# Cuantos shards por nodo pueden ser asignados concurrentemente en un determinado momento. Puede provocar problemas de IO. cluster.routing.allocation.node_concurrent_recoveries:4 # Número de shards que se pueden inicializar concurrentemente en un nodo. cluster.routing.allocation.node_initial_primaries_recoveries:18 # Numero de streams paralelos transferidos desde otro nodo a la hora de recuperar fragmentos. # 4 es el valor propuesto recomendable para Amazon EC, si es con hardware local se debe subir. indices.recovery.concurrent_streams:4 # Cuantos bytes por segundo son transferidos por segundos en dichas recuperaciones de shards, se debe adaptar al hardware. indices.recovery.max_bytes_per_sec: 40mb
Un split brain se produce cuando en un cluster ES hay más de un nodo que pasa a ser “master”, esto puede ser debido a cortes en la red, apagado de ciertos servidores, etc. Como los nodos maestros son los que administran el clúster y deciden a donde, cuando y como va cada shard y su réplica, si hay más de uno, se pueden perder datos
La opción “minimum_master_nodes” previene a ES de elegir un nodo maestro mientras haya suficientes nodos maestros elegibles disponibles. Esta propiedad define una cantidad mínima de los nodos maestro elegibles que deben ser conectados entre sí con el fin de formar un clúster.
Formula: quórum = (Número de nodos que pueden ser master / 2) +1
Este valor siempre debe estar configurado para un quórum (mayoría) de los nodos-maestros elegibles.
Esta directiva se puede configurar con las opciones de clúster de forma que no haya que editar todos los ficheros de configuración de todos los nodos.
PUT /_cluster/settings { "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } }
Las opciones pueden ser persistentes (persistent), las cuales sobrescriben los ficheros de configuración o temporales (transtient), siendo deshabilitadas después de un reinicio.
Qué opciones pueden cambiarse dinámicamente: https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-update-settings.html
Un fragmento en elasticsearch es un índice Lucene, y un índice de Lucene se divide en segmentos. Los segmentos son ficheros donde los datos del índice son almacenados, estos son inmutables. Cuantos más segmentos se tengan, más lentas son las búsquedas y más memoria utilizan.
El fusionado de segmentos ayuda a tener menos número de segmentos pero esa acción requiere de mucha actividad de I/O y procesamiento de CPU. El fusionado (mergen) se realiza periódicamente en segundo plano (background) y puede coincidir que ocurra justo cuando hay una indexación en marcha. Cuando esto sucede, Elasticsearch reduce las solicitudes de indexación a un solo hilo para evitar que se generan cientos de segmentos antes de que puedan ser fusionados. Esto queda reflejado en los logs de ES con nivel INFO.
Como no se quiere que las búsquedas sean afectadas por ese procesado de fusión, estas se limitan a 20 MB/s, que está muy bien para discos no SSD pero es recomendable elevar en discos SSD a 100 - 200 Mb.
PUT /_cluster/settings { "persistent" : { "indices.store.throttle.max_bytes_per_sec" : "100mb" } }
Si se está realizando una importación por lotes (Bulk) y no hay que preocuparse por el rendimiento de las búsquedas, se puede desactivar dicha limitación, permitiendo indexar todo lo rápido que el disco duro pueda.
PUT /_cluster/settings { "transient" : { "indices.store.throttle.type" : "none" } }
Una vez se haya importado se le puede volver a dar el valor de “merge” a la directiva.
Lo anterior se refiere a discos SSD, si se dispone de discos no SSD se debe agregar la siguiente directiva al fichero de configuración “elasticsearch.yml”. Con esto se consigue reducir el número de hilos que pueden acceder a disco por cada índice. La siguiente directiva responde a la siguiente formula: max_thread_count + 2.
Limitar a 3 los hilos que puedan operar concurrentemente.
index.merge.scheduler.max_thread_count: 1
Con discos en estado sólido se puede ignorar ya que por defecto toma el valor “Math.min(3, Runtime.getRuntime().availableProcessors() / 2)”, que es el óptimo para la tecnología SSD.
Se puede modificar el límite usado para reducir esas solicitudes de indexación, fijadas para discos duros no SSD a 20 por defecto. Si se utilizan discos SSD es recomendable aumentarla más, entre 100 y 200 Mb.
Para contrarrestar operaciones de Entrada y salida que puedan provocar problemas de rendimiento es también posible configurar “index.translog.flush_threshold_size” cuyo valor por defecto es 200 Mb. Puede ser recomendable elevarlo a 1Gb, ya que al tener un valor mayor, los segmentos son fusionados y limpiados menos frecuentemente.
Si se necesita reiniciar un nodo por una actualización o reinicio del sistema operativo, conviene dar a conocer al clúster que no realice tareas de resignación de fragmentos ya que pronto volverá a estar en linea el nodo. Con esto se evitan problemas de rendimiento al reconstruir el nuevo esquema del clúster al estar el nodo offline. Se debe proceder de la siguiente manera.
1.- Desactivar la indexación de datos cuando sea posible.
2.- Desactivar rebalanceo de shards.
PUT /_cluster/settings { "transient" : { "cluster.routing.allocation.enable" : "none" } }
3.- Apagar el servicio ElsticSearch.
POST /_cluster/nodes/_local/_shutdown
4.- Realizar la tarea de mantenimiento que se deba.
5.- Arrancar de nuevo ES y confirmas que todo funciona correctamente.
PUT /_cluster/settings { "transient" : { "cluster.routing.allocation.enable" : "all" } }
Si por ejemplo se actualizó la versión de ElasticSearch del nodo, se debe repetir el mismo proceso en cada uno de los nodos que forman parte del clúster.
Optimizaciones en la definición del mapping.
HTTP es más rápido que HTTPS.
Si se tienen pocos nodos, tal vez sea recomendable que el número de shards se establezca a 3 -5.
El número de fragmentos (shards) no es modificable una vez creado el índice, pero sí lo son las réplicas. Es posible empezar con indices que no contengan replicas y una vez realizada la carga, crear las réplicas, eso mejora de sobremanera el rendimiento de una indexación.
Si no se necesita tiempo real en los resultados de las búsquedas se puede configurar el valor de index.refresh_interval de cada índice en 30s (por defecto es 1s). Si se va a hacer una gran importación de documentos, esta se puede desactivar mientras dure la indexación usando el valor -1. Recordar volver a su valor original una vez terminada la indexación.
Si se usan IDs en los documentos, se recomienda usar el nativo de ES (auto-ID), de lo contrario se recomienda utilizar uno compatible con Lucene (Leer).
Debido a que muchas veces el cuello de botella es el propio cliente, se pueden paralelizar indexaciones utilizando múltiples clientes de manera simultanea.
Si el cliente usa Java, se debe considerar el uso de NodeClient.
Consultas a la API HTTP: Mejor utilizar “HTTP keep alive (HTTP/1.0)” que “HTTP chunking (HTTP/1.1)”.
Desactivar borrado de todos los índices (Seguro frente a meteduras de pata).
action.disable_delete_all_indices
Buscar consultar lentas / registrarlas en los logs.
Por defecto slowlog no está habilitado, este tipo de registro se puede emplear para registrar consultas lentas en búsqueda y solicitudes de indexación. (Leer)
Otra recomendación importante es la de no tocar la configuración predeterminada de la máquina virtual de Java (JVM).
Como probar la configuración de ElasticSearch en base al rendimiento.
Ejemplo de Error: Unable to lock JVM memory (ENOMEM)
Causa: Mala configuración de Elasticsearch (mlockall / memlock unlimited).
Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being swapped out. Increase RLIMIT_MEMLOCK (ulimit).
Solución: Con lo mostrado anteriormente es fácil deducir esta serie de instrucciones.
### Consultar y establecer los límites del sistema para el usuario elasticsearch.
su elasticsearch --shell /bin/bash --command "ulimit -l"
64
### Crear el fichero /etc/security/limits.d/elasticsearch.conf con el siguiente contenido.
elasticsearch - nofile 262144
elasticsearch - memlock unlimited
### Comprobar los limites.
su elasticsearch --shell /bin/bash --command "ulimit -l"
unlimited
### Comprobar la configuración del parámetro mlockall en elasticsearch.yml
bootstrap.mlockall: true
### Editar /etc/init.d/elasticsearch.
MAX_LOCKED_MEMORY=unlimited
LimitMEMLOCK=infinity
### Reiniciar Elasticsearch y comprobar.
service elasticsearch restart
curl http://elastic_node1:9200/_nodes/elastic_node1/process/?pretty
{
"cluster_name" : "dm-log",
"nodes" : {
"7A_E72FPRJe44qpsaMeuTw" : {
"name" : "elastic_node1",
"transport_address" : "inet[80.10.220.125/80.10.220.125:9300]",
"host" : "elastic1.dominio.com",
"ip" : "80.10.220.125",
"version" : "1.7.2",
"build" : "b88f43f",
"http_address" : "inet[/80.10.220.125:9200]",
"attributes" : {
"master" : "false"
},
"process" : {
"refresh_interval_in_millis" : 1000,
"id" : 29502,
"max_file_descriptors" : 262144,
"mlockall" : true <----------------- :-)
}
}
}
}
Dependiendo de la configuración del proxy reverso que se use con elasticsearch, puede que se tengan los típicos errores de gateway o proxy timeout, algo muy habitual de ver en Kibana bajo entornos mal configurados. A continuación se muestra una configuración básica especificando las variables que se deben adaptar (en segundos). La configuración utiliza autenticación básica y HTTPS.
Elasticsearch Nginx frontend + HTTPS + Basic authentication.
server {
listen 443 ssl;
server_name www.dominio.com;
client_max_body_size 999M;
client_body_buffer_size 1M;
####### SSL.
ssl_certificate /etc/nginx/fichero.cer;
ssl_certificate_key /etc/nginx/fichero.key;
access_log off;
location / {
auth_basic "ElasticSearch Cluster.";
auth_basic_user_file /etc/nginx/usuarios; # Autenticación HTTP.
proxy_pass http://127.0.0.1:9200; # Configuración del proxy + timeouts.
proxy_max_temp_file_size 0;
proxy_redirect off;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
send_timeout 300;
}
}
Enlaces de interés: