¿Cómo soluciono un problema de excepción de interrupción en Amazon OpenSearch Service?

Última actualización: 01/09/2021

Intento enviar datos a mi clúster de Amazon OpenSearch Service (sucesor de Amazon Elasticsearch Service). Sin embargo, recibo un error de excepción de interrupción que indica que el volumen de mis datos es demasiado grande. ¿Por qué sucede esto y cómo puedo resolverlo?

Descripción corta

Cuando una solicitud llega a los nodos de OpenSearch Service, las interrupciones calculan la cantidad de memoria necesaria para cargar los datos requeridos. A continuación, OpenSearch Service compara el tamaño estimado con el límite de tamaño del montón configurado. Si el tamaño estimado de los datos es mayor que el tamaño del montón disponible, la consulta se termina. Como resultado, se lanza CircuitBreakerException para evitar sobrecargar el nodo.

OpenSearch Service utiliza las siguientes interrupciones para evitar las excepciones JVM OutofMemoryError:

  • Solicitud
  • Fielddata
  • In flight requests
  • Accounting
  • Principal

Nota: Es importante saber cuál de estas cinco interrupciones generó la excepción porque cada una de ellas tiene sus propias necesidades de ajuste. Para obtener más información sobre los tipos de interrupción, consulte Configuración de interrupción en el sitio web de Elasticsearch.

Para obtener el uso actual de la memoria por nodo y por interrupción, utilice el siguiente comando:

GET _nodes/stats/breaker

Además, tenga en cuenta que las interrupciones son solo un mecanismo de mejor esfuerzo. Si bien las interrupciones proporcionan cierta resistencia contra la sobrecarga de un nodo, es posible que aún reciba un error OutOfMemoryError. Las interrupciones solo pueden realizar un seguimiento de la memoria si está reservada explícitamente, por lo que no siempre es posible estimar el uso exacto de la memoria por adelantado. Por ejemplo, si tiene una pequeña cantidad de memoria de montón, la sobrecarga relativa de la memoria no rastreada es mayor. Para obtener más información sobre las interrupciones y la resistencia de los nodos, consulte Mejorar la resistencia de los nodos con la interrupción de memoria real en el sitio web de Elasticsearch.

Para evitar sobrecargar los nodos de datos, siga las sugerencias de la sección Solución de problemas de presión elevada de la memoria de JVM.

Resolución

Excepción de interrupción

Si utiliza Elasticsearch versión 7.x o superior con 16 GB de montón, aparecerá el siguiente error cuando se alcance el límite de interrupción:

"error": {
        "root_cause": [
            {
                "type": "circuit_breaking_exception",
                "reason": "[parent] Data too large, data for [<http_request>] would be [16355096754/15.2gb], which is larger than the limit of [16213167308/15gb], real usage: [15283269136/14.2gb], new bytes reserved: [1071827618/1022.1mb]",
               }
      ]
}

La salida de este ejemplo indica que el volumen de datos que se va a procesar es demasiado grande para que los gestione la interrupción principal. La interrupción principal (un tipo de interrupción) es responsable del uso general de la memoria del clúster. Cuando se produce una excepción de interrupción principal, la memoria total utilizada en todas las interrupciones ha superado el límite establecido. Una interrupción principal emite una excepción cuando el clúster supera el 95 % de los 16 GB, es decir, 15,2 GB del almacenamiento dinámico.

Puede verificar esta lógica al calcular la diferencia entre el uso de memoria y el límite establecido de la interrupción. Utilice los valores de la salida de nuestro ejemplo y reste el “uso real: [15283269136/14.2gb]” del “límite de [16213167308/15gb]”. Este cálculo muestra que esta solicitud necesita alrededor de 1,02 GB de memoria reservada de bytes nuevos para procesar correctamente la solicitud. Sin embargo, en este ejemplo, el clúster tenía menos de 0,8 GB de memoria de montón libre disponible cuando se recibió la solicitud de datos. Como resultado, se activa la interrupción.

El mensaje de excepción de interrupción se puede interpretar así:

  • datos correspondientes a [ ]: el cliente envía solicitudes HTTP a un nodo del clúster. OpenSearch Service procesa la solicitud a nivel local o la pasa a otro nodo para su procesamiento adicional.
  • sería [#]: cómo se ve el tamaño de la memoria de montón cuando se procesa la solicitud.
  • límite de [#]: límite actual de interrupción.
  • uso real: uso real del montón de JVM.
  • nuevos bytes reservados: memoria real necesaria para procesar la solicitud.

Presión de la memoria de JVM

Una excepción de interrupción suele deberse a una presión elevada de la memoria de JVM. La presión de la memoria de JVM se refiere al porcentaje de montón de Java que se utiliza para todos los nodos de datos del clúster. Consulte la métrica JVMMemoryPressure en Amazon CloudWatch para determinar el uso actual.

Nota: El tamaño del montón de la JVM para un nodo de datos se establece en la mitad del tamaño de la memoria física (RAM), hasta 32 GB. Por ejemplo, si la memoria física (RAM) es de 128 GB por nodo, el tamaño del montón todavía será de 32 GB (el tamaño máximo del montón). De lo contrario, el tamaño del almacenamiento dinámico se calcula como la mitad del tamaño de la memoria física.

La presión elevada de la memoria de JVM puede deberse a lo siguiente:

  • Aumento del número de solicitudes al clúster. Consulte las métricas IndexRate y SearchRate de Amazon CloudWatch para determinar la carga actual.
  • Agregación, comodines y uso de amplios intervalos de tiempo en las consultas.
  • Asignaciones de particiones desequilibradas entre nodos o demasiadas particiones en un clúster.
  • Explosiones de mapeo de índices.
  • Utilización de la estructura de datos fielddata para consultar datos. Fielddata puede consumir una gran cantidad de espacio del montón y permanecer en este durante la vida útil de un segmento. Como resultado, la presión de la memoria de JVM se mantiene elevada en el clúster cuando se utiliza fielddata. Para obtener más información, consulte Fielddata en el sitio web de Elasticsearch.

Solución de problemas de presión elevada de la memoria de JVM

Para resolver la presión elevada de la memoria de JVM, intente con las siguientes sugerencias:

  • Reduzca el tráfico entrante hacia el clúster, especialmente si tiene una carga de trabajo pesada.
  • Considere la posibilidad de escalar el clúster para obtener más memoria de JVM que admita su carga de trabajo.
  • Si no es posible escalar el clúster, intente reducir el número de particiones al eliminar los índices antiguos o no utilizados. Debido a que los metadatos de las particiones se almacenan en la memoria, reducir el número de particiones puede disminuir el uso general de la memoria.
  • Habilite los registros lentos para identificar las solicitudes defectuosas.
    Nota: Antes de habilitar los cambios de configuración, compruebe que la presión de la memoria JVM sea inferior al 85 %. De esta forma, puede evitar sobrecargas adicionales a los recursos existentes.
  • Optimice las solicitudes de búsqueda e indexación y elija el número correcto de particiones. Para obtener más información sobre la indexación y el recuento de particiones, consulte Introducción a Amazon OpenSearch Service: ¿cuántas particiones necesito?
  • Desactive y evite el uso de fielddata. De forma predeterminada, fielddata se establece en “falso” en un campo de texto a menos que se defina explícitamente de otra manera en los mapeos de índices.
  • Cambie el tipo de mapeo de índices a palabra clave mediante la API reindex o la API create or update index template. Puede utilizar el tipo de palabra clave como alternativa para realizar agregaciones y ordenar los campos de texto.
  • No realice agregaciones en los campos de texto para evitar aumentos en los datos de campo. Cuando utiliza más datos de campo, se consume más espacio del montón. Utilice la operación de la API cluster stats para verificar los datos del campo.
  • Borre la memoria caché de fielddata con la siguiente llamada a la API:
POST /index_name/_cache/clear?fielddata=true (index-level cache)
POST */_cache/clear?fielddata=true (cluster-level cache)

Advertencia: Si borra la memoria caché de fielddata, es posible que se interrumpa cualquier consulta en curso.

Para obtener más información, consulte ¿Cómo se pueden solucionar problemas de presión elevada de memoria de JVM en el clúster de Amazon OpenSearch Service?