¿Cómo soluciono los problemas de uso elevado de la CPU en mi clúster de Amazon OpenSearch Service?

Descripción breve

Se recomienda mantener la utilización de la CPU para asegurarse de que OpenSearch Service tenga suficientes recursos para realizar sus tareas. Un clúster que funcione de manera consistente con un uso elevado de la CPU puede degradar el rendimiento del clúster. Cuando el clúster está sobrecargado, OpenSearch Service deja de responder, lo que provoca una solicitud de tiempo de espera.

Para solucionar problemas de uso elevado de la CPU en el clúster, considere los siguientes enfoques:

• Utilice la API nodes hot threads .
• Compruebe la operación de escritura o el grupo de subprocesos de API masivos .
• Compruebe el grupo de subprocesos de búsqueda .
• Compruebe el grupo de subprocesos de combinación de Apache Lucene.
• Compruebe la presión de la memoria de la JVM.
• Revise su estrategia de partición.
• Optimice sus consultas.

Resolución

Utilice la API de nodes hot threads

Si hay picos constantes de CPU en su clúster de OpenSearch Service, utilice la API nodes hot threads . La API de nodes hot threads actúa como un administrador de tareas y le muestra el desglose de todos los subprocesos que consumen muchos recursos que se ejecutan en su clúster.

Ejemplo de salida de la API de nodes hot threads :

GET _nodes/hot_threads

100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

**Nota:**La salida de nodes hot threads muestra la información de cada nodo. La longitud de la salida depende del número de nodos que se estén ejecutando en el clúster de OpenSearch Service.

Además, utilice la API de cat nodes para ver el desglose actual de la utilización de los recursos. Puede reducir el subconjunto de nodos con la mayor utilización de la CPU con el siguiente comando:

GET _cat/nodes?v&s=cpu:desc

La última columna de la salida muestra el nombre del nodo. Para obtener más información, consulte la API de cat nodes en el sitio web de Elasticsearch.

Luego, transfiera el nombre del nodo correspondiente a su API de hot threads :

GET _nodes/<node-name>/hot_threads

Para obtener más información, consulte la API de Hot threads en el sitio web de Elasticsearch.

Ejemplo de salida de nodes hot threads :

<percentage> of cpu usage by thread 'opensearch[<nodeName>][<thread-name>]'

El nombre del subproceso indica qué procesos de OpenSearch Service consumen mucha CPU.

Para obtener más información, consulte la API de nodes hot threads en el sitio web de Elasticsearch.

Compruebe la operación de escritura o el grupo de subprocesos de API masivos

Un error 429 en OpenSearch Service puede indicar que su clúster está gestionando demasiadas solicitudes de indexación masiva. Cuando hay picos constantes de CPU en su clúster, OpenSearch Service rechaza las solicitudes de indexación masiva.

El grupo de subprocesos de escritura gestiona las solicitudes de indexación, que incluyen operaciones de API masivas. Para confirmar si su clúster gestiona demasiadas solicitudes de indexación masiva, compruebe la métrica de IndexingRate en Amazon CloudWatch.

Si su clúster gestiona demasiadas solicitudes de indexación masiva, considere los siguientes enfoques:

• Reduzca la cantidad de solicitudes masivas en su clúster.
• Reduzca el tamaño de cada solicitud masiva para que sus nodos puedan procesarlas de manera más eficiente.
• Si se usa Logstash para enviar datos a su clúster de OpenSearch Service, reduzca el tamaño del lote o la cantidad de trabajadores.
• Si la tasa de ingesta de su clúster se ralentiza, escale su clúster (horizontal o verticalmente). Para ampliar su clúster, aumente la cantidad de nodos y el tipo de instancia para que OpenSearch Service pueda procesar las solicitudes entrantes.

Para obtener más información, consulte la API masiva en el sitio web de Elasticsearch.

Compruebe el grupo de subprocesos de búsqueda

Un grupo de subprocesos de búsqueda que consume mucha CPU indica que las consultas de búsqueda están sobrecargando su clúster de OpenSearch Service. Su clúster puede verse sobrecargado por una sola consulta de larga duración. El aumento de las consultas realizadas por su clúster también puede afectar a su grupo de subprocesos de búsqueda .

Para comprobar si una sola consulta, aumente el uso de la CPU, use la API de administración de tareas . Por ejemplo:

GET _tasks?actions=*search&detailed

La API de administración de tareas obtiene todas las consultas de búsqueda activas que se ejecutan en su clúster. Para obtener más información, consulte la API de administración de tareas en el sitio web de Elasticsearch.

Nota: El resultado solo incluye el campo de descripción si hay una tarea de búsqueda mostrada por la API de administración de tareas .

Ejemplo de salida:

{
    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

Compruebe el campo de descripción para identificar qué consulta se está ejecutando. El campo running_time_in_nanos indica la cantidad de tiempo que ha estado ejecutándose una consulta. Para reducir el uso de la CPU, cancele la consulta de búsqueda que consuma mucha CPU. La API de administración de tareas también admite una llamada de _cance .

Nota: Asegúrese de registrar el ID de la tarea de la salida para cancelar una tarea en particular. En este ejemplo, el ID de la tarea es «U4M_p_x2Rg6YqLujeInPOw:53506997».

Ejemplo de llamada de POST de administración de tareas :

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

La llamada de POST de administración de tareas marca la tarea como «cancelada» y libera todos los recursos de AWS dependientes. Si tiene varias consultas en ejecución en su clúster, utilice la llamada de POST para cancelar las consultas una por una. Cancele cada consulta hasta que el clúster vuelva a su estado normal. También se recomienda establecer un valor de tiempo de espera en el cuerpo de la consulta para evitar picos elevados de CPU. Para obtener más información, consulte Solicitar parámetros de búsqueda de cuerpos en el sitio web de Elasticsearch. Para comprobar si el número de consultas activas ha disminuido, compruebe la métrica SearchRate en Amazon CloudWatch.

Nota: Cancelar todas las consultas de búsqueda activas al mismo tiempo en el clúster de OpenSearch Service puede provocar errores en la aplicación del cliente.

Para obtener más información, consulte grupos de subprocesos en el sitio web de Elasticsearch.

Compruebe el grupo de subprocesos de combinación de Apache Lucene

OpenSearch Service usa Apache Lucene para indexar y buscar documentos en su clúster. Apache Lucene ejecuta operaciones de combinación para reducir el número efectivo de segmentos necesarios para cada fragmento y eliminar cualquier documento eliminado. Este proceso se ejecuta cada vez que se crean nuevos segmentos en una partición.

Si observa que una operación de subprocesos de combinación de subprocesos de Apache Lucene afecta al uso de la CPU, aumente la configuración refresh_interval de los índices del clúster de OpenSearch Service. El aumento de la configuración refresh_interval ralentiza la creación de segmentos del clúster.

Nota: Un clúster que migre los índices al almacenamiento UltraWarm puede aumentar el uso de la CPU. Una migración de UltraWarm suele implicar una operación de API de combinación forzada que puede requerir un uso intensivo de la CPU.

Para comprobar si hay migraciones de UltraWarm, utilice el siguiente comando:

GET _ultrawarm/migration/_status?v

Para obtener más información, consulte Combinación en el sitio web de Elasticsearch.

Compruebe la presión de la memoria de la JVM

Revise el porcentaje de presión de memoria de JVM del montón de Java en un nodo de clúster. Si la presión de memoria de JVM alcanza el 75%, Amazon OpenSearch Service activa el recolector de elementos no utilizados de Concurrent Mark Sweep (CMS). Si la presión de memoria de JVM alcanza el 100%, la JVM de OpenSearch Service está configurada para salir y, finalmente, reiniciarse en OutOfMemory (OOM).

En el siguiente registro de ejemplo, la JVM se encuentra dentro del rango recomendado, pero el clúster se ve afectado por la prolongada recolección de elementos no utilizados:

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService]
[515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]
collecting in the last [10.2s]

Para obtener más información, consulte ¿Cómo soluciono los problemas de alta presión de memoria de JVM en mi clúster de Amazon OpenSearch Service?

Revise su estrategia de fragmentación

Según el tamaño del clúster, es posible que el rendimiento del clúster disminuya si hay demasiados fragmentos. Se recomienda no tener más de 25 particiones por GiB de montón de Java.

De forma predeterminada, Amazon OpenSearch Service tiene una estrategia de fragmentación de 5:1, en la que cada índice se divide en cinco fragmentos principales. Dentro de cada índice, cada fragmento principal también tiene su propia réplica. OpenSearch Service asigna automáticamente las particiones principales y las particiones de réplica a nodos de datos independientes y se asegura de que haya una copia de seguridad en caso de error.

Para obtener más información, consulte ¿Cómo puedo reequilibrar la distribución desigual de fragmentos en mi clúster de Amazon OpenSearch Service?

Optimice sus consultas

Las agregaciones pesadas, las consultas comodín (especialmente los caracteres comodín principales) y las consultas de expresiones regulares pueden resultar costosas desde el punto de vista computacional y provocar picos de utilización de la CPU. La búsqueda de registros lentos y la indexación de registros lentos pueden ayudarle a diagnosticar consultas costosas y problemáticas.

Para obtener más información, consulte Supervisión de los registros de OpenSearch con Amazon CloudWatch Logs.

Información relacionada

¿Cómo puedo mejorar el rendimiento de indexación en mi clúster de Amazon OpenSearch Service?

¿Cómo puedo resolver los rechazos de búsqueda o escritura en Amazon OpenSearch Service?

Ajustar el tamaño de los dominios de Amazon OpenSearch Service