Recientemente, Elasticsearch 5.4 (ES) es una versión relativamente nueva. Hay muchos problemas durante el uso, que es un dolor de cabeza, pero el problema finalmente se resolvió.
Pregunta 1: Esclient es lento, y el cliente no se puede obtener: no pudo crear un bucle de evento infantil
Debido a que el negocio necesita cargar un lote de archivos sin cargar un índice ES, debe obtener una conexión y luego operar cada vez que agrega un índice. Especialmente en grandes lotes, el número de adquisiciones es obviamente muy grande. La razón principal de este problema es que con frecuencia operamos en bucles. Por ejemplo, necesitamos obtener 100 archivos en un lote. Para reducir el tiempo de obtener el cliente ES, finalmente adoptamos una solución, es decir, inicializar la conexión cuando se inicia el servicio, obtenerlo a la vez y luego llamarlo directamente más tarde. Después de cargar todo el archivo por lotes, finalmente se agrega el índice ES, en lugar de agregar un archivo a la vez. Obviamente, este método no requiere que cada lote obtenga conexiones, lo que mejora enormemente la eficiencia de la ejecución.
Primero, cuando se inicia el servicio, inicializamos el cliente estático ES en la clase de inicio:
Private static elasticsearchutil elasticsearchutil = new ElasticsearchUtil (); Public Static TransportClient Client = ElasticSearchUtil.getClient ();
Luego llámelo directamente cuando se use:
Client Client = main.client;
Esto puede reducir en gran medida el número de conexiones al cliente ES, mejorando así la eficiencia.
El código ES es el siguiente:
Public TransportClient getClient () {String [] iparr = configUtil.getValue ("esip"). Split (","); settings settings = settings.builder (). put ("shiff_pool.generic.core", 5) .put ("thread_pool.generic.max", 10) .put ("procesadores", 5) .put (constants.esclustername, configUtil.getValue ("clustername")). build (); transportlient client = new PreBuiltTransportClient (configuración); for (string ip: iparr) {transportAddress dirección = nueva inetSocketTransportAddress (inetAddresses.forString (IP), 9300); client.addtransportaddresses (dirección);} Return Client;}Pregunta 2: Overflow de memoria: java.lang.OUTOFMEMORY: No se puede crear un nuevo hilo nativo
Durante el proceso de desarrollo del proyecto, el desbordamiento de la memoria es algo muy problemático. Lo encontré durante el uso de ES, y era muy frecuente, especialmente durante las pruebas de estrés a gran escala. Pensé en muchas maneras de optimizar la memoria JVM, pero no hubo efecto, y el problema aún no se resolvió. Finalmente, al mirar el código fuente, encontré una razón. Combinado con excepciones de informes de errores, esto se debe a que una gran cantidad de hilos se crearon automáticamente durante el uso con ES, que excedió la capacidad del sistema, lo que condujo al desbordamiento de la memoria. Al estudiar el código fuente, descubrí que el número de hilos creados por ES se puede controlar a través de la configuración. Aquí está el número predeterminado de hilos de creación de ES:
thread_pool.generic.core = valor predeterminado --- 4thread_pool.generic.max = valor predeterminado-min (512, max (4*número de procesador, 128)) Número de procesador = Número de procesador CPU
Nuestra CPU es de 10 núcleos y 40 hilos
A juzgar por los resultados del cálculo, si se usa el valor predeterminado, el número de subprocesos que ES puede crear es un gran valor, que está mucho más allá de la capacidad del sistema en sí. Ajusta principalmente el valor de configuración. Después del ajuste, cambiamos el valor predeterminado de ES como sigue:
Configuración Settings = settings.Builder (). Put ("Thread_pool.Generic.Core", 5) .put ("Thread_pool.Generic.max", 10) .put ("Processors", 5) .put (constants.esclustername, configUtil.getValue ("clustername")). Build ();; Esta es la configuración anterior settings = settings.builder (). Put ("Thread_pool.Generic.Core", 5) .put (constants.esclustername, configUtil.getValue ("clustername")). Build ();Después de las pruebas, ES creó un número muy pequeño de hilos y satisface nuestras necesidades de desarrollo, y no hubo ningún problema de desbordamiento de memoria nuevamente.
El resumen anterior de las preguntas comunes basadas en Elasticsearch 5.4 es todo el contenido que comparto con usted. Espero que pueda darle una referencia y espero que pueda apoyar más a Wulin.com.