¿Qué es el derrame del operador en GaussDB(DWS)?
Durante la ejecución de la consulta, si la memoria del clúster es insuficiente, la base de datos elegirá almacenar los resultados temporales en el disco. Cuando el almacenamiento en disco utilizado por los resultados temporales excede un cierto valor, los usuarios recibirán una alarma: "data spilling exceeds the threshol" (el derrame de datos excede el umbral). ¿Qué significa derrame?
Derrame del operador a los discos
Cualquier ordenador consume espacio de memoria. Si se consume demasiada memoria, la memoria para ejecutar otros trabajos será insuficiente, lo que hará que se ejecute un trabajo inestable. Por lo tanto, debe limitar el uso de memoria de las instrucciones de consulta para garantizar la estabilidad de ejecución del trabajo.
Si un trabajo que se ejecuta requiere 500 MB de memoria pero solo se le asignan 300 MB de memoria, los datos que no se utilizan temporalmente deben escribirse en los discos, y solo los datos que se están utilizando se conservan en la memoria. Esto se llama derrame de datos. También se llama operator spilling. El gran tamaño de los datos derramados al disco puede causar un uso del disco del 100%. Si sucede, la base de datos pasará a ser de solo lectura y el rendimiento de la consulta se verá muy afectado. Por lo tanto, GaussDB(DWS) impone un límite al derrame del operador. Si el derrame del operador excede el límite, se notifica un error y la consulta sale.
¿Qué operadores pueden derramar?
Los operadores que pueden derramarse al disco son Hash(VecHashJoin), Agg(VecAgg), Sort(VecSort), Material(VecMaterial), SetOp(VecSetOp) y WindowAgg(VecWindowAgg). Pueden estar vectorizados o no vectorizados.
¿Qué parámetros se pueden utilizar para controlar el derrame del operador?
- work_mem: establece el umbral de derrame. El uso del disco que exceda este parámetro causará que el operador se derrame. Este parámetro solo tiene efecto cuando la memoria no es autoadaptable.(enable_dynamic_workload=off). Garantiza el rendimiento simultáneo y el rendimiento de un único trabajo de consulta. Por lo tanto, es necesario optimizar el parámetro basado en la salida de Explain Performance.
- temp_file_limit: limita el tamaño de los archivos derramados en los discos. Se recomienda establecer este parámetro en función de los requisitos del sitio para evitar que los archivos derramados consuman el espacio en disco. Los archivos derramados que excedan el valor de este parámetro provocarán un error.
¿Cómo sé si un estado de cuenta se derrama en discos?
- Compruebe los archivos de derrames. Los archivos de derrame se almacenan en el directorio base/pgsql_tmp del directorio de instancia. Los archivos de derrames se denominan pgsql_tmp$queryid_$pid. Puede determinar qué instrucción de SQL se derrama en el disco basándose en el queryid.
- Verifique la vista de espera (pgxc_thread_wait_status). Si se muestra write file en la vista de espera, hay resultados temporales derramados a los discos.
- Verifique el plan de ejecución (EXPLAIN PERFORMANCE). Palabras clave como spill, written disk y temp file num indican que hay un operador que se derrama.
- Compruebe si la columna spill_info en TopSQL en tiempo real o Historical TopSQLcontiene la información derrame. Si esta columna no está vacía, los datos se han derramado a los discos de los DN. (Requisito: Se ha habilitado la función topsql.)
¿Cómo evito el derrame?
Cuando los operadores se derraman en los discos, los datos de cálculo del operador se escriben en los discos. En comparación con el acceso a la memoria, las operaciones del disco son lentas, lo que provoca un deterioro del rendimiento y el deterioro del tiempo de respuesta a las consultas. Por lo tanto, trate de evitar que el operador se derrame durante la ejecución de la consulta. Se recomienda utilizar los siguientes métodos:
- Reducir el conjunto de resultados intermedios: Si el conjunto de resultados intermedios es demasiado grande, puede agregar criterios de filtro para reducir el tamaño del conjunto de resultados intermedios.
- Evitar el sesgo de datos: Si hay un sesgo de datos grave, se producirá un derrame en un DN que tiene una gran cantidad de datos.
- Realizar ANALYZE de manera oportuna: cuando las estadísticas son inexactas, se puede estimar que el número de filas es menor. Como resultado, el plan no es óptimo y los datos se derraman a los discos.
- Realizar optimización de un solo punto: Realizar optimización en sentencias SQL individuales.
- Si la memoria no es autoadaptable, y el conjunto de resultados intermedio no se puede reducir, aumente el valor de work_mem como sea apropiado.
- Si la memoria es autoadaptable, aumente la memoria disponible de la base de datos tanto como sea posible para reducir la probabilidad de derramamiento de datos.
