Un error OOM (Out of Memory) ocurre cuando una consulta excede la memoria disponible en Hologres. Este tema explica cómo monitorear el uso de memoria, identificar errores OOM y resolverlos.
Análisis del consumo de memoria
-
Consulte el consumo de memoria
Consumo total: La consola de Hologres muestra el consumo de memoria agregado de todos los nodos. Para obtener más información, consulte Monitoring metrics.
Consumo por consulta: El campo
memory_bytesaproxima el consumo de memoria por consulta. Este valor puede ser impreciso. Para obtener más información, consulte Get and analyze slow query logs.
-
Gestión del alto uso de memoria
Monitoree el uso general de memoria en la consola de Hologres (consulte Monitoring metrics). Un uso sostenido superior al 80% se considera alto. Hologres preasigna memoria para metadatos y caché, por lo que un uso en reposo del 30-50% es normal. Un uso cercano al 100% degrada la estabilidad y el rendimiento.
-
Causas
-
Alto consumo de memoria por metadatos
La memoria de metadatos crece con el volumen de tablas y puede causar un uso elevado incluso cuando no hay tareas en ejecución. Mantenga cada Table Group por debajo de 10,000 tablas (incluidas las particiones, excluyendo las tablas externas). Un número excesivo de shards en un Table Group aumenta la fragmentación y la sobrecarga de metadatos.
-
Alto consumo de memoria por cómputo
El alto consumo de memoria en consultas suele deberse al escaneo de grandes volúmenes de datos o a operaciones complejas como múltiples funciones
COUNT DISTINCT, operacionesJOINcomplejas,GROUP BYen varias columnas o funciones de ventana. -
Alto uso de memoria en el módulo Other
Cuando el monitoreo de memoria muestra un aumento repentino en el uso de memoria del módulo Other junto con una alta utilización general de memoria, la causa puede ser el parámetro experimental
hg_experimental_enable_hash_partitioned_sort_v2. Este parámetro habilita un algoritmo de ordenamiento con particiones hash para el filtrado de números de fila de ventana. El algoritmo tiene problemas conocidos de consumo de recursos y provoca que la memoria no clasificada se acumule bajo la categoría del módulo Other.Solución
Deshabilite el parámetro experimental ejecutando la siguiente sentencia SQL:
SET hg_experimental_enable_hash_partitioned_sort_v2 = off;Después de deshabilitar este parámetro, monitoree el uso de memoria de la instancia. La memoria atribuida al módulo Other debería disminuir a niveles normales.
-
-
Impactos clave
-
Estabilidad
El consumo excesivo de memoria, especialmente por metadatos, reduce la memoria disponible para las consultas y puede causar errores esporádicos como
SERVER_INTERNAL_ERROR,ERPC_ERROR_CONNECTION_CLOSEDoTotal memory used by all existing queries exceeded memory limitation. -
Rendimiento
El alto uso de memoria por exceso de metadatos agota el espacio de caché, lo que reduce las tasas de aciertos de caché y aumenta la latencia de las consultas.
-
-
Soluciones
Si el alto uso de memoria se debe a un exceso de metadatos: Utilice la tabla
hg_table_infopara gestionar sus tablas. Para obtener más información, consulte Query and analyze table statistics. Elimine los datos o tablas no utilizados y reduzca las particiones innecesarias para liberar memoria.Si el alto uso de memoria se debe al cómputo: Optimice el SQL para los casos de uso de escritura y consulta por separado. Para obtener más información, consulte Resolve OOM errors during queries y Resolve OOM errors during data import and export.
Solución general: Escale verticalmente los recursos de cómputo y almacenamiento. Instance list.
-
Identificación de errores OOM
Un error OOM ocurre cuando la memoria de cómputo excede su límite asignado (por ejemplo, 20 GB o más). Un mensaje de error típico:
Total memory used by all existing queries exceeded memory limitation.
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100Interprete el mensaje de error de la siguiente manera:
-
queries=(query_id, memory_used_by_query)Cada entrada, como
queries=(2031xxxx,184yy), muestra el consumo de memoria por consulta. Por ejemplo,queries=(2031xxxx,18441803528)significa que la consultaquery_id=2031xxxxconsumió ~18 GB en un solo nodo. Se enumeran las 5 consultas con mayor consumo de memoria. Para obtener más información, consulte Get and analyze slow query logs. -
Used/Limit: xy1/xy2Muestra
compute_memory_used_on_node/compute_memory_limit_on_nodeen bytes.Usedes la memoria de cómputo total consumida por todas las consultas en ejecución en ese nodo. Por ejemplo,Used/Limit: 33288093696/33114697728significa que las consultas usaron 33.2 GB, superando el límite de 33.1 GB y desencadenando un OOM. -
quota/sum_quota: zz/100zzes el porcentaje de los recursos totales de la instancia asignados a un resource group. Por ejemplo,quota/sum_quota: 50/100significa que el resource group utiliza el 50% de los recursos totales de la instancia.
Causas básicas de los errores OOM
Hologres prioriza el cómputo en memoria para lograr una eficiencia óptima en las consultas. A diferencia de los sistemas que descargan datos al disco cuando la memoria es insuficiente, Hologres genera un error OOM directamente cuando una consulta excede la memoria disponible.
Asignación y límites de memoria
Una instancia de Hologres opera como un sistema distribuido, compuesto por múltiples nodos cuya cantidad varía según las especificaciones de la instancia. Para obtener más detalles, consulte Instance management.
Cada nodo suele tener 16 vCPU y 64 GB de memoria. Se produce un error OOM si algún nodo agota su memoria. Los 64 GB se dividen entre cómputo de consultas, procesos de backend, caché y metadatos. Antes de la versión V1.1.24, la memoria de cómputo tenía un límite máximo de 20 GB. La versión V1.1.24 y posteriores asignan dinámicamente la memoria disponible a las consultas cuando el consumo de metadatos es bajo.
Resolución de errores OOM durante consultas
-
Causas.
Planes de ejecución incorrectos: Esto puede deberse a estadísticas inexactas, un orden de unión inadecuado u otros problemas de optimización.
Alta concurrencia de consultas: Muchas consultas consumen simultáneamente una cantidad considerable de memoria.
Consultas complejas: Consultas inherentemente complejas o aquellas que escanean grandes volúmenes de datos.
Operaciones
UNION ALL: Las consultas que contienenUNION ALLpueden aumentar el paralelismo del ejecutor, lo que resulta en un mayor uso de memoria.Asignación insuficiente de resource group: Se configuró un resource group pero se le asignaron recursos inadecuados.
Sesgo de datos o poda de shards: Estos factores pueden causar una carga desequilibrada y una alta presión de memoria en nodos específicos.
-
Análisis y soluciones:
-
Causa: Asignación insuficiente de resource group
Solución: Utilice la función Serverless Computing para complementar los recursos dedicados de su instancia con capacidad de cómputo adicional. Para obtener una descripción general e instrucciones de uso, consulte Serverless computing y Work with serverless computing.
En Hologres V3.0 y versiones posteriores, Query Queues vuelve a ejecutar automáticamente las consultas OOM en recursos de serverless computing. Control large queries.
-
Causa: Plan de ejecución incorrecto
-
Tipo 1: Estadísticas inexactas
Ejecute
EXPLAIN <SQL>para ver el plan de ejecución.rows=1000indica que faltan estadísticas o son inexactas, lo que genera un plan de ejecución ineficiente que consume recursos excesivos y desencadena un error OOM.tt=# explain select count(1) from tmp join tmp1 on tmp.a = tmp1.b; QUERY PLAN ---------------------------------------------------------------------------------- Partial Aggregate (cost=0.00..10.11 rows=1 width=8) -> Gather Motion (cost=0.00..10.11 rows=10 width=8) -> Partial Aggregate (cost=0.00..10.11 rows=10 width=8) -> Hash Join (cost=0.00..10.11 rows=1 width=1) Hash Cond: (tmp.a = tmp1.b) -> Parallelism (Gather Exchange) (cost=0.00..5.04 rows=1000 width=1) -> DecodeNode (cost=0.00..5.04 rows=1000 width=1) -> Seq Scan on tmp (cost=0.00..5.01 rows=1000 width=1) -> Hash (cost=5.04..5.04 rows=1000 width=1) -> Parallelism (Gather Exchange) (cost=0.00..5.04 rows=1000 width=1) -> DecodeNode (cost=0.00..5.04 rows=1000 width=1) -> Seq Scan on tmp1 (cost=0.00..5.01 rows=1000 width=1) Optimizer: HQO version 0.8.0 (13 rows)Las soluciones incluyen lo siguiente:
Ejecute el comando
ANALYZE <tablename>para actualizar las estadísticas de la tabla.Habilite el análisis automático para actualizar las estadísticas automáticamente. Para obtener más información, consulte ANALYZE and AUTO ANALYZE.
-
Tipo 2: Orden de unión incorrecto
En un Hash Join, la tabla más pequeña debe ser el lado de construcción. Use
EXPLAIN <SQL>para verificar el plan de ejecución. Si la tabla más grande construye la tabla hash, el orden de unión es ineficiente y puede causar OOM. Razones comunes:-
Estadísticas de tabla obsoletas. Por ejemplo, las estadísticas de la tabla superior no se actualizaron, lo que resultó en
rows=1000.En el plan de ejecución, el nodo Result en el lado izquierdo del Hash Left Join tiene un recuento estimado de filas de solo 1,000, mientras que el lado de construcción Hash en la derecha tiene un recuento estimado de hasta 6,754,108,416 (aproximadamente 6.75 mil millones). Esta gran discrepancia indica que se utilizó la tabla grande para construir la tabla Hash.
Gather (cost=0.00..56428622.14 rows=6754109416 width=496) -> Insert (cost=0.00..49020180.01 rows=6754109416 width=496) -> Result (cost=0.00..79269.98 rows=6754109416 width=742) -> Hash Left Join (cost=0.00..54211.24 rows=6754109416 width=660) Hash Cond: (row_pk = dws_tb_crm_itm_prf_exp_analysis_nd.row_pk) -> Result (cost=0.00..7.03 rows=1000 width=600) -> Redistribution (cost=0.00..6.01 rows=1000 width=496) -> Result (cost=0.00..6.00 rows=1000 width=496) Filter: ((ds = ‘${bizdate}’::text) AND (NOT (row_pk IS NULL))) -> Forward (cost=0.00..6.00 rows=1000 width=504) -> Sequence (cost=0.00..5.00 rows=1000 width=504) -> Partition Selector for dws_tb_crm_itm_prf_exp_analysis_nd_extl (dynamic scan id: 1) (cost=10.00..100.00 rows=100 width=4) Partitions selected: 0 (out of 33) -> DynamicSeqScan (cost=0.00..5.00 rows=1000 width=504) -> Hash (cost=11717.79..11717.79 rows=6754108416 width=60) -> Exchange (Gather Exchange) (cost=0.00..11717.79 rows=6754108416 width=60) -> Decode (cost=0.00..2755.96 rows=6754108416 width=60) -> Seq Scan on dws_tb_crm_itm_prf_exp_analysis_nd (cost=0.00..871.47 rows=6754108416 width=60) Optimizer: HQO version 0.10.0 (19 rows) El optimizador no pudo generar un plan de ejecución óptimo.
Soluciones:
Ejecute
ANALYZE <tablename>en todas las tablas involucradas en la unión para asegurar que las estadísticas estén actualizadas. Esto ayuda al optimizador a determinar el orden de unión correcto.-
Si el orden de unión sigue siendo incorrecto después de ejecutar
ANALYZE <tablename>, ajuste un parámetro GUC. Establezcaoptimizer_join_order = querypara forzar al optimizador a seguir la secuencia de unión especificada en la sentencia SQL. Este enfoque es particularmente adecuado para consultas complejas.SET optimizer_join_order = query; SELECT * FROM a JOIN b ON a.id = b.id; -- Table b is used as the build side of the hash table.También puede ajustar la directiva de orden de unión según sea necesario.
Parámetro
Descripción
set optimizer_join_order = <value>
Este parámetro controla el algoritmo de orden de unión del optimizador. Valores válidos:
-
query: No realiza transformación de orden de unión. Las uniones se ejecutan estrictamente en el orden especificado en la consulta SQL. Esta configuración implica la menor sobrecarga para el optimizador. -
greedy: Emplea un algoritmo voraz para explorar posibles órdenes de unión. Esta opción resulta en una sobrecarga moderada del optimizador. -
exhaustive(predeterminado): Utiliza un algoritmo de planificación dinámica para la transformación del orden de unión. Su objetivo es generar el plan de ejecución óptimo, pero conlleva la mayor sobrecarga para el optimizador.
-
-
-
Tipo 3: Estimación incorrecta de la tabla hash
En una unión hash, la entrada más pequeña debe construir la tabla hash. Sin embargo, la complejidad de la consulta o estadísticas inexactas pueden hacer que el sistema seleccione una relación más grande como entrada de construcción, creando una tabla hash sobredimensionada que desencadena un OOM.
Hash (cost=727353.45..627353.35 , rows=970902134 width=94)representa la entrada de construcción, yrows=970902134indica el volumen de datos estimado para construir la tabla hash. Si la tabla real contiene menos datos, la estimación es inexacta.El nodo Hash en la parte inferior del plan de ejecución tiene un recuento estimado de filas de hasta
rows=970902134(aproximadamente 970 millones de filas), lo cual es un síntoma típico de que el volumen de datos del lado de construcción está severamente sobreestimado o seleccionado incorrectamente.-> Broadcast (cost=0.00..5.17 rows=119488 width=16) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=16) -> Decode (cost=0.00..5.10 rows=1867 width=16) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=16) -> Hash (cost=5.17..5.17 rows=119488 width=16) -> Broadcast (cost=0.00..5.17 rows=119488 width=16) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=16) -> Decode (cost=0.00..5.10 rows=1867 width=16) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=16) -> Hash (cost=5.13..5.13 rows=119488 width=8) -> Broadcast (cost=0.00..5.13 rows=119488 width=8) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=8) -> Decode (cost=0.00..5.10 rows=1867 width=8) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=8) -> Hash (cost=5.10..5.10 rows=896 width=3) -> Broadcast (cost=0.00..5.10 rows=896 width=3) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=14 width=3) -> Decode (cost=0.00..5.10 rows=14 width=3) -> Seq Scan on xxx (cost=0.00..5.00 rows=14 width=3) -> Hash (cost=627353.45..627353.45 rows=970902134 width=94) -> Partial HashAggregate (cost=0.00..627353.45 rows=970902134 width=94)Soluciones:
Verifique las estadísticas: Compruebe si las estadísticas de la tabla de la subconsulta están actualizadas y son precisas. De lo contrario, ejecute
ANALYZE <tablename>para actualizarlas.-
Deshabilitar la estimación de la tabla hash: Desactive la estimación de la tabla hash del motor de ejecución mediante el siguiente parámetro:
NotaEste parámetro tiene como valor predeterminado
off. Sin embargo, podría haberse habilitado en ciertos escenarios de ajuste. Si actualmente está habilitado, asegúrese de restablecerlo aoff.SET hg_experimental_enable_estimate_hash_table_size =off;
-
Tipo 4: Difusión de una tabla grande
La difusión copia datos a todos los shards y es eficiente solo para tablas pequeñas con pocos shards. Durante las uniones, la entrada de construcción se difunde a cada shard. Un conjunto de datos grande o un número excesivo de shards pueden consumir una cantidad sustancial de memoria, causando errores OOM.
Por ejemplo, una tabla de 80 millones de filas podría mostrar solo 1 fila estimada en el plan de ejecución. La difusión real de los 80 millones de filas consume memoria excesiva, lo que desencadena un OOM.
Gather (cost=0.00..119000614.54 rows=495989952 width=5537) -> Insert (cost=0.00..112801537.07 rows=495989952 width=5537) -> Redistribution (cost=0.00..428813.57 rows=991979904 width=2320) -> Result (cost=0.00..338771.55 rows=991979904 width=2320) -> Result (cost=0.00..338771.55 rows=991979904 width=2320) -> Hash Left Join (cost=0.00..310003.14 rows=991979904 width=5561) Hash Cond: ((olap_event_1480807263997566978.pub_distinct_id = olap_event_1480807263997566978_new.pub_distinct_id) AND (olap_event_1480807263997566978.pub_event_name = olap_event_1480807263997566978_new.pub_event_name) AND (olap_event_1480807263997566978.uuid = olap_event_1480807263997566978_new.uuid)) -> Exchange (Gather Exchange) (cost=0.00..68102.40 rows=495989952 width=5537) -> Decode (cost=0.00..65774.92 rows=495989952 width=5537) -> Seq Scan on olap_event_1480807263997566978 (cost=0.00..1923.43 rows=495989952 width=5537) -> Hash (cost=5.10..5.10 rows=80 width=24) -> Broadcast (cost=0.00..5.10 rows=80 width=24) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1 width=24) -> Decode (cost=0.00..5.10 rows=1 width=24) -> Seq Scan on olap_event_1480807263997566978_new (cost=0.00..5.00 rows=1 width=24) Optimizer: HQO version 1.1.0Soluciones:
Compruebe si el recuento estimado de filas en el plan de ejecución coincide con la realidad. De lo contrario, ejecute
ANALYZE tablenamepara actualizar las estadísticas.-
Deshabilite la difusión y reescríbala como un operador de redistribución mediante el siguiente parámetro GUC.
SET optimizer_enable_motion_broadcast = off;
-
-
Causa: Alta concurrencia de consultas
Si el QPS aumenta significativamente, o el error OOM muestra
HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy);con cada consulta usando memoria mínima, la causa probable es la alta concurrencia. Soluciones:Reducir la concurrencia de escritura: Si las operaciones de escritura contribuyen al problema, reduzca su concurrencia. Para obtener más información, consulte Resolve OOM errors during data import and export.
Implementar separación de lectura/escritura: Despliegue un read/write splitting architecture with primary and secondary instances (shared storage).
Aumente las especificaciones de cómputo de su instancia.
-
Causa: Consulta compleja
Si una sola consulta desencadena un OOM debido a su complejidad o gran volumen de datos, considere estos enfoques:
Precomputar datos: Escriba datos precomputados en Hologres para evitar operaciones ETL a gran escala dentro de Hologres.
Agregar condiciones de filtro.
Optimizar SQL: Utilice técnicas como Fixed Plan u optimización Count Distinct. Para obtener más información, consulte Optimize internal table query performance.
-
Causa: UNION ALL
Como se muestra a continuación, cuando una sentencia SQL contiene muchas subconsultas
UNION ALL, el ejecutor las procesa concurrentemente. Esto puede sobrecargar la memoria y causar un error OOM.subquery1 UNION ALL subquery2 UNION ALL subquery3 ...Solución: Fuerce la ejecución en serie utilizando los siguientes parámetros para mitigar los errores OOM. Tenga en cuenta que esto resultará en un rendimiento de consulta más lento.
SET hg_experimental_hqe_union_all_type=1; SET hg_experimental_enable_fragment_instance_delay_open=on; -
Causa: Configuración inadecuada de resource group
Un error OOM reporta:
memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100. Si zz es pequeño (por ejemplo, 10, lo que significa solo 10% de recursos asignados), las consultas en ese grupo tienen memoria limitada, lo que aumenta la probabilidad de OOM.AcquireOrRelease] HGERR code 53200 HGERR msge Total memory used by all existing queries exceeded memory limitation. HGERR detl memory usage for existing queries=(7001xxx 5,4367295472)(673125xxx9,1701576)(6731xxx 3,3590736)(6731xxx 5,3510024) (673116xxx ,3088256 Used/Limit: 4408213504/42552795136 quota/sum_quota: 10/100.Solución: Restablezca la cuota del resource group. Asigne como mínimo
30%de los recursos totales de la instancia a cada resource group. -
Causa: Sesgo de datos o poda de shards
Si el uso general de memoria es bajo pero aún ocurre un OOM, el sesgo de datos o la poda de shards podrían estar concentrando la presión de memoria en nodos específicos.
NotaLa poda de shards es una técnica de optimización de consultas que escanea solo un subconjunto de shards, en lugar de todos ellos.
-
Comprobar sesgo de datos: Utilice la siguiente consulta SQL. El campo
hg_shard_ides un campo oculto integrado en cada tabla que indica el shard donde reside cada fila.SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id; -
Inspeccionar poda de shards: Inspeccione el plan de ejecución en busca de indicios de poda de shards. Por ejemplo, si el selector de shards muestra
l0[1], significa que solo se seleccionaron los datos de un shard específico para la consulta.-- The distribution key is x. Based on the filter condition x=1, you can quickly locate the shard. SELECT count(1) FROM bbb WHERE x=1 GROUP BY y;QUERY PLAN -------------------------------------------------------------- Result (cost=0.00..5.10 rows=1 width=8) -> HashAggregate (cost=0.00..5.10 rows=1 width=8) Group Key: y -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1 width=4) -> Decode (cost=0.00..5.10 rows=1 width=4) -> Seq Scan on bbb (cost=0.00..5.00 rows=1 width=4) Filter: (x = 1) Shard Selector(Eagerly): ->: l0 [1] Optimizer: HQO version 1.3.0 (10 rows)
Soluciones:
Diseñe una clave de distribución adecuada para prevenir el sesgo de datos.
Si la lógica de negocio causa inherentemente sesgo de datos, modifique la lógica de la aplicación en consecuencia.
-
-
Causa: GROUP BY de múltiples etapas con alta cardinalidad
En Hologres V3.0 y versiones posteriores, las agregaciones de múltiples etapas en datos de alta cardinalidad pueden causar OOM cuando las columnas de
GROUP BYno se alinean con la clave de distribución (la clave de distribución no es un subconjunto de la clave deGROUP BY). Cada instancia concurrente mantiene una tabla hash grande, lo que crea una alta presión de memoria. Para mitigar esto, establezca el siguiente parámetro:-- Use a GUC parameter to set the maximum number of rows in the aggregation hash table. The following SQL statement indicates that the partial_agg_hash_table can have a maximum of 8192 rows. The default value is 0, which indicates no limit. SET hg_experimental_partial_agg_hash_table_size = 8192;
-
Resolución de errores OOM durante la importación y exportación de datos
Los errores OOM pueden ocurrir durante las transferencias de datos en Hologres, incluidas las transferencias entre tablas internas, interacciones con tablas externas e importaciones desde MaxCompute.
-
Solución 1: Usar Serverless Computing para importaciones y exportaciones
Utilice Serverless Computing para complementar los recursos de su instancia en tareas de importación y exportación, evitando la contención de recursos. Para obtener una descripción general, consulte Serverless computing. Para instrucciones de uso, consulte Work with serverless computing.
-
Solución 2: Controlar la concurrencia de escaneo para tablas o columnas anchas
En las importaciones de MaxCompute, los errores OOM pueden surgir de tablas o columnas anchas combinadas con una alta concurrencia de escaneo. Utilice los siguientes parámetros para controlar la concurrencia.
-
Controlar la concurrencia de escaneo para tablas anchas (escenario común)
NotaAplique los siguientes parámetros junto con su sentencia SQL. Priorice los dos primeros parámetros. Si persiste un error OOM, reduzca aún más sus valores.
-- Set the maximum concurrency for accessing foreign tables. The default value equals the instance's vCPU count. The maximum value is 128. Do not set a large value to prevent queries on foreign tables, especially in data import scenarios, from affecting other queries and causing system busy errors. This parameter is effective in Hologres V1.1 and later. SET hg_foreign_table_executor_max_dop = 32; -- Adjust the batch size for each read from a MaxCompute table. The default value is 8192. SET hg_experimental_query_batch_size = 4096; -- Set the maximum concurrency for executing DML statements when accessing foreign tables. The default value is 32. This parameter is optimized for data import and export scenarios to prevent import operations from consuming excessive system resources. This parameter is effective in Hologres V1.1 and later. SET hg_foreign_table_executor_dml_max_dop = 16; -- Set the split size for accessing MaxCompute tables. This parameter can adjust concurrency. The default value is 64 MB. If the table is large, increase this value to prevent too many splits from affecting performance. This parameter is effective in Hologres V1.1 and later. SET hg_foreign_table_split_size = 128; -
Controlar la concurrencia de escaneo para columnas anchas
Si ya ajustó los parámetros para tablas anchas pero aún encuentra errores OOM, compruebe si sus datos incluyen columnas anchas. De ser así, ajuste los siguientes parámetros para resolver el problema.
-- Adjust the shuffle parallelism for wide columns to reduce data accumulation. SET hg_experimental_max_num_record_batches_in_buffer = 32; -- Adjust the batch size for each read from a MaxCompute table. The default value is 8192. SET hg_experimental_query_batch_size=128;
-
-
Causa: Datos duplicados excesivos en una tabla externa
Cuando una tabla externa contiene una cantidad sustancial de datos duplicados, el rendimiento de importación se degrada y puede causar errores OOM. Por ejemplo, una tabla de 100 millones de filas con 80 millones de duplicados tiene un alto nivel de duplicación. Evalúe la duplicación según su contexto de negocio.
Solución: Deduplique los datos antes de la importación o importe en lotes más pequeños.
¿Qué causa el error "The shards are incomplete, the workers or shards are unhealthy"?
Este error generalmente no es causado directamente por un problema de falta de memoria (OOM). Ocurre cuando el uso de CPU de la instancia de Hologres es excesivamente alto, lo que provoca que los nodos Worker o los Shards entren en un estado no saludable.
Para resolver este problema:
Consulte las métricas de monitoreo de la instancia de Hologres para comprobar si el uso de CPU está elevado.
Si el uso de CPU es alto, espere a que disminuya la carga de trabajo y luego reintente la consulta.
Si el error persiste, compruebe si consultas complejas o una concurrencia excesiva están causando saturación de CPU. Optimice las consultas que consumen muchos recursos o reduzca la concurrencia para disminuir el uso de CPU.