Vinculación de diferentes grupos de recursos a dos tipos de trabajos para equilibrar la carga en DWS
Esta práctica demuestra cómo utilizar DWS para la gestión de la carga de recursos, lo que ayuda a las empresas a eliminar los cuellos de botella en las consultas simultáneas. Los trabajos de SQL pueden ejecutarse sin problemas sin afectarse entre sí y consumir menos recursos que antes.
Esta práctica dura unos 60 minutos. El proceso es el siguiente:
- Paso 1: Creación de un clúster
- Paso 2: Conexión a un clúster e importación de datos
- Paso 3: Creación de un grupo de recursos
- Paso 4: Verificación de reglas de excepción
Escenarios
Cuando varios usuarios de bases de datos ejecutan trabajos de SQL en DWS al mismo tiempo, pueden ocurrir las siguientes situaciones:
- Algunas instrucciones SQL complejas ocupan recursos del clúster durante mucho tiempo, lo que afecta el rendimiento de otras consultas. Por ejemplo, un grupo de usuarios de bases de datos envía continuamente consultas complejas y que consumen mucho tiempo, mientras que otro grupo de usuarios envía con frecuencia consultas cortas. En este caso, las consultas cortas pueden tener que esperar en el grupo de recursos para que se completen las consultas que consumen mucho tiempo.
- Algunas instrucciones SQL ocupan demasiada memoria o espacio en disco debido a la distorsión de datos o a planes de ejecución no optimizados. Como resultado, las sentencias que no pueden solicitar memoria reportan errores o el clúster cambia al modo de solo lectura.
Para aumentar el throughput del sistema y mejorar el rendimiento de SQL, puede utilizar la gestión de cargas de trabajo de DWS. Por ejemplo, cree un grupo de recursos para los usuarios que envían con frecuencia trabajos de consultas complejas y asigne más recursos a este grupo de recursos. Los trabajos complejos enviados por estos usuarios solo pueden utilizar los recursos de este grupo de recursos. Cree otro grupo de recursos que ocupe menos recursos y agregue usuarios que envíen consultas cortas a este grupo de recursos. De esta manera, los dos tipos de trabajos se pueden ejecutar sin problemas al mismo tiempo.
Por ejemplo, el usuario A procesa servicios de procesamiento de transacciones en línea (OLTP) y procesamiento analítico en línea (OLAP). La prioridad del servicio OLAP es inferior a la del servicio OLTP. Una gran cantidad de consultas SQL complejas y concurrentes puede causar la contención de recursos del servidor, mientras que una gran cantidad de consultas SQL simples y concurrentes se puede procesar rápidamente sin entrar en cola. Los recursos deben asignarse y gestionarse correctamente para garantizar que los servicios OLAP y OLTP se ejecuten sin problemas.
Los servicios OLAP suelen ser complejos y no requieren una alta prioridad ni una respuesta en tiempo real. Los servicios OLAP y OLTP son operados por diferentes usuarios. Por ejemplo, el usuario de la base de datos budget_config_user se utiliza para los servicios de transacciones principales, y el usuario de la base de datos report_user se utiliza para los servicios de reportes. Los usuarios están bajo una gestión independiente de CPU y simultaneidad para mejorar la estabilidad de la base de datos.
Según la encuesta de carga de trabajo, el monitoreo de rutina y la prueba y verificación de los servicios OLAP, se ha encontrado que menos de 50 consultas SQL concurrentes no causan contención de recursos del servidor ni una respuesta lenta del sistema de servicio. Los usuarios de OLAP pueden utilizar el 20 % de los recursos de CPU.
Según la encuesta de carga de trabajo, el monitoreo de rutina y la prueba y verificación de los servicios OLTP, se ha encontrado que menos de 100 consultas SQL concurrentes no ejercen una presión continua sobre el sistema. Los usuarios de OLTP pueden utilizar el 60 % de los recursos de CPU.
- Configuración de recursos para usuarios de OLAP (correspondiente a pool_1): CPU = 20 %, memoria = 20 %, almacenamiento = 1,024,000 MB, simultaneidad = 20.
- Configuración de recursos para usuarios de OLTP (correspondiente a pool_2): CPU = 60 %, memoria = 60 %, almacenamiento = 1,024,000 MB, simultaneidad = 200.
Establezca la memoria máxima que puede ser utilizada por una sola sentencia. Se reportará un error si el uso de memoria excede el valor.
En Exception Rule, establezca Blocking Time en 1200s y Execution Time en 1800s. Un trabajo de consulta se terminará después de ejecutarse durante más de 1800 segundos.
Paso 2: Conexión a un clúster e importación de datos
- Utilice el cliente para conectarse al clúster.
- Importe datos de ejemplo. Para obtener más información, consulte Importación de datos TPC-H.
- Ejecute las siguientes sentencias para crear el usuario OLTP budget_config_user y el usuario OLAP report_user.
1 2
CREATE USER budget_config_user PASSWORD 'password'; CREATE USER report_user PASSWORD 'password';
- Con fines de prueba, otorgue todos los permisos de todas las tablas del esquema tpch a ambos usuarios.
1GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA tpch to budget_config_user,report_user;
- Verifique la asignación de recursos de los dos usuarios.
1SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO where username in ('budget_config_user' , 'report_user');

Paso 3: Creación de un grupo de recursos
- Inicie sesión en la consola de DWS. En la lista de clústeres, haga clic en el nombre de un clúster y cambie a la página Resource Management.
- Haga clic en Add Workload Queue. Cree el grupo de recursos de reporte pool_1 y el grupo de recursos de transacción pool_2 consultando Escenarios.


- Modifique las reglas de excepción.
- Haga clic en el pool_1 creado.
- En el área Exception Rule, configure Blocking Time en 1200s y Execution Time en 1800s.
- Haga clic en Save.
- Repita los pasos anteriores para configurar pool_2.

- Asocie usuarios.
- Haga clic en pool_1 a la izquierda.
- Haga clic en Add a la derecha de User Association.
- Seleccione report_user y haga clic en OK.
- Repita los pasos anteriores para agregar budget_config_user a pool_2.


Paso 4: Verificación de reglas de excepción
- Inicie sesión en la base de datos como usuario report_user.
- Ejecute el siguiente comando para verificar el grupo de recursos al que pertenece el usuario report_user:
1SELECT usename,respool FROM pg_user WHERE usename = 'report_user';

El resultado de la consulta muestra que el grupo de recursos al que pertenece el usuario report_user es pool_1.
- Verifique la regla de excepción vinculada al recurso grupo pool_1.
1SELECT respool_name,mem_percent,active_statements,except_rule FROM pg_resource_pool WHERE respool_name='pool_1';

Se confirma que la regla de excepción rule_1 está vinculada a pool_1.
- Vea el tipo de regla y el umbral de la regla de excepción para el usuario actual.
1SELECT * FROM pg_except_rule WHERE name = 'rule_1';

El resultado muestra que rule_1 tiene 1200 segundos de tiempo de bloqueo y 1800 segundos de duración de ejecución.
- PG_EXCEPT_RULE registra información sobre las reglas de excepción y solo se admite en el clúster 8.2.0 o posterior.
- La relación entre los parámetros de la misma regla de excepción es AND.
- Cuando el tiempo de bloqueo de un trabajo supera los 1200 s y la duración de ejecución supera los 1800 s, se muestra un mensaje de error que indica que se ha activado la regla de excepción y que se ha cancelado el trabajo.

Si se muestra información de error similar a "ERROR: canceling statement due to workload manager exception." durante la ejecución del trabajo, el trabajo se interrumpe porque supera el umbral de la regla de excepción. Si no es necesario modificar las reglas, debe optimizar las sentencias de servicio para reducir el tiempo de ejecución.