Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Implementación de WLM manual Con la WLM manual, puede administrar el rendimiento del sistema y la experiencia de los usuarios mediante la modificación de la configuración de la WLM para crear colas independientes para las consultas de ejecución prolongada y las de ejecución corta. Cuando los usuarios ejecutan consultas en Amazon Redshift, estas se dirigen a las colas de consultas. Cada cola de consultas contiene un número de slots de consultas. A cada cola se le asigna una parte de la memoria disponible del clúster. La memoria de una cola se divide entre los slots de consultas de la cola. Puede habilitar Amazon Redshift para administrar la simultaneidad de las consultas con la WLM automática. Para obtener más información, consulte [Implementación de WLM automática](automatic-wlm.md). O puede configurar las propiedades de WLM para cada cola de consulta. Lo hace para especificar la forma en que se asigna la memoria entre ranuras y cómo se pueden dirigir las consultas a colas específicas en tiempo de ejecución. También es posible configurar propiedades de WLM para cancelar consultas de ejecución prolongada. De forma predeterminada, Amazon Redshift configura las siguientes colas de consultas: + **Una cola de superusuario** La cola de superusuario está reservada únicamente para superusuarios y no se puede configurar. Utilice esta cola solo cuando necesite ejecutar consultas que afectan al sistema o para solucionar problemas. Por ejemplo, utilice esta cola cuando necesite cancelar una consulta de ejecución prolongada de un usuario o para añadir usuarios a la base de datos. No la utilice para realizar consultas de rutina. La cola no aparece en la consola, pero sí lo hace en las tablas de sistema de la base de datos como la quinta cola. Para ejecutar una consulta en la cola de superusuario, es necesario que un usuario inicie sesión como superusuario y debe ejecutar la consulta mediante el grupo de consultas predefinido `superuser`. + **Una cola de usuario predeterminada** La cola predeterminada está configurada inicialmente para ejecutar cinco consultas de forma simultánea. Al usar WLM manual, puede cambiar las propiedades de simultaneidad, tiempo de espera y asignación de memoria para la cola predeterminada, pero no puede especificar grupos de usuarios ni de consultas. La cola predeterminada debe ser la última cola en la configuración de WLM. Cualquier consulta que no se direccione a otras colas se ejecuta en la cola predeterminada. Las colas de consultas se definen en la configuración de WLM. La configuración de WLM es un parámetro modificable (`wlm_json_configuration`) de un grupo de parámetros, que puede estar asociado a uno o más clústeres. Para obtener más información, consulte [Configuración de la administración de cargas de trabajo](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) en la *Guía de administración de Amazon Redshift*. Puede añadir colas de consultas adicionales a la configuración de WLM predeterminada, hasta llegar a un total de ocho colas de usuario. Para cada cola de consultas, puede configurar lo siguiente: + Modo de escalado de simultaneidad + Nivel de simultaneidad + Grupos de usuarios + Grupos de consultas + Porcentaje de memoria de WLM por utilizar + Tiempo de espera de WLM + Salto de cola de consultas de WLM + Reglas de monitorización de consultas ## Modo de escalado de simultaneidad Cuando el escalado de simultaneidad está habilitado, Amazon Redshift agrega capacidad del clúster de manera automática si se necesita para procesar un aumento de las consultas de lectura y escritura simultáneas. Los usuarios ven siempre los datos más actualizados, tanto si las consultas se ejecutan en el clúster principal como si se ejecutan en un clúster de escalado de simultaneidad. Puede administrar qué consultas se envían al clúster de escalado de simultaneidad configurando colas de WLM. Cuando habilita el escalado de simultaneidad para una cola, las consultas elegibles se envían al clúster de escalado de simultaneidad en lugar de esperar en la cola. Para obtener más información, consulte [Escalado de simultaneidad](concurrency-scaling.md). ## Nivel de simultaneidad Las consultas de una cola se ejecutan simultáneamente hasta que se alcanza el número de slots de consultas de WLM o el nivel de* simultaneidad* definido para esa cola. Las consultas posteriores esperan en la cola. **nota** El nivel de simultaneidad de WLM es distinto del número de conexiones de usuario simultáneas que se pueden realizar en un clúster. Para obtener más información, consulte [Conexión a un clúster](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html) en la *Guía de administración de Amazon Redshift*. En una configuración de WLM automática, que es la recomendada, el nivel de simultaneidad se establece a **Automático**. Amazon Redshift asigna memoria de forma dinámica a las consultas y, posteriormente, determina cuántas se ejecutarán de forma simultánea. Se basa en los recursos necesarios tanto para las consultas en ejecución como para las que están en cola. No se puede configurar WLM automática. Para obtener más información, consulte [Implementación de WLM automática](automatic-wlm.md). En una configuración de WLM manual, Amazon Redshift asigna de forma estática una cantidad fija de memoria a cada cola. La memoria de la cola se divide en partes iguales entre las ranuras de consulta. A modo de ejemplo, si a una cola se le asigna el 20 % de la memoria de un clúster y tiene 10 ranuras, a cada consulta se le asigna el 2 % de la memoria del clúster. La asignación de memoria permanece fija independientemente del número de consultas que se ejecuten de forma simultánea. Debido a esta asignación de memoria fija, las consultas que se ejecutan completamente en la memoria cuando el número de ranuras es 5, puede que deba escribir resultados intermedios en el disco si el número de ranuras aumenta a 20. En este caso, la cuota de memoria de la cola correspondiente a cada consulta se reduce de un 1/5 a un 1/20. La E/S adicional del disco puede degradar el rendimiento. El número máximo de ranuras de consultas para todas las colas definidas por el usuario es de 50. Esto limita el total de ranuras para todas las colas, incluida la cola predeterminada. La única cola que no está sujeta al límite es la cola de superusuario reservada. De forma predeterminada, las colas de WLM manuales tienen un nivel de simultaneidad de 5. La carga de trabajo puede beneficiarse de un nivel de simultaneidad más alto en determinados casos, como los siguientes: + Si hay muchas consultas pequeñas que tienen que esperar a que se ejecuten las consultas largas, cree una cola independiente con un mayor número de slots y asigne las consultas pequeñas a esa cola. Una cola con un nivel de simultaneidad más alto tiene menos memoria asignada a cada slot de consultas, pero las consultas más pequeñas requieren menos memoria. **nota** Si habilita la aceleración de consultas cortas (SQA), WLM dará prioridad automáticamente a las consultas cortas frente a las largas, por lo que no será necesario que separe la cola de las consultas cortas en la mayoría de los flujos de trabajo. Para obtener más información, consulte [Aceleración de consultas cortas](wlm-short-query-acceleration.md). + Si varias colas tienen acceso a los datos de un mismo sector, configure una cola de WLM independiente para ejecutar esas consultas de manera simultánea. Amazon Redshift asigna consultas simultáneas a diferentes sectores, lo que permite que varias consultas se ejecuten en paralelo en distintos sectores. Por ejemplo, si una consulta es un conjunto simple con un predicado en la clave de distribución, los datos para la consulta se ubican en un sector único. ### Un ejemplo de WLM manual Este ejemplo es un escenario de WLM sencillo y manual para mostrar cómo se pueden asignar las ranuras y la memoria. La WLM manual se implementa con tres colas, que son las siguientes: + *cola de ingesta de datos*: está configurada para ingerir datos. Se le asigna el 20 % de la memoria del clúster y tiene 5 ranuras. Posteriormente, se pueden ejecutar 5 consultas de forma simultánea en la cola y a cada una se le asigna el 4 % de la memoria. + *cola de científicos de datos*: está diseñada para consultas que consumen mucha memoria. Se le asigna el 40 % de la memoria del clúster y tiene 5 ranuras. Posteriormente, se pueden ejecutar 5 consultas de forma simultánea y a cada una se le asigna el 8 % de la memoria. + *cola predeterminada*: está diseñada para la mayoría de los usuarios de la organización. Se incluyen los grupos de ventas y contabilidad que normalmente tienen consultas de corta o mediana duración que no son complicadas. Se le asigna el 40 % de la memoria del clúster y tiene 40 ranuras. Se pueden ejecutar 40 consultas simultáneamente en esta cola y a cada consulta se le asigna el 1 % de la memoria. Es el número máximo de ranuras que se pueden asignar a esta cola, ya que el límite entre todas las colas es de 50. Si ejecuta WLM automática y su carga de trabajo requiere que más de 15 consultas se ejecuten en paralelo, le recomendamos que active el escalado de simultaneidad. El motivo es que, al aumentar el número de ranuras de consulta por encima de 15, se podría provocar la contención de los recursos del sistema y que se limitara el rendimiento general de un único clúster. Con el escalado de simultaneidad, puede ejecutar cientos de consultas en paralelo hasta alcanzar el número de clústeres de escalado de simultaneidad establecido. [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md) controla el número de clústeres de escalado de simultaneidad. Para obtener más información acerca del escalado de simultaneidad, consulte [Escalado de simultaneidad](concurrency-scaling.md). Para obtener más información, consulte [Mejora del rendimiento de las consultas](query-performance-improvement-opportunities.md). ## Grupos de usuarios Puede asignar un conjunto de grupos de usuarios a una cola especificando cada nombre de grupo de usuarios o utilizando comodines. Cuando un miembro de un grupo de usuarios de la lista ejecuta una consulta, esa consulta se ejecuta en la cola correspondiente. No hay un límite establecido en cuanto al número de grupos de usuarios que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de consultas a las colas en función de los grupos de usuarios](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups). ## Funciones de usuario Puede asignar un conjunto de roles de usuarios a una cola especificando cada nombre de rol de usuarios o utilizando comodines. Cuando un miembro de un rol de usuario de la lista ejecuta una consulta, esa consulta se ejecuta en la cola correspondiente. No hay un límite establecido en cuanto al número de roles de usuarios que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de consultas a las colas en función de los roles de usuarios](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles). ## Grupos de consultas Puede asignar un conjunto de grupos de consultas a una cola especificando cada nombre de grupo de consultas o utilizando comodines. Un grupo de consultas es sencillamente una etiqueta. En tiempo de ejecución, puede asignar la etiqueta de grupo de consultas a un conjunto de consultas. Cualquier consulta que se asigne a un grupo de consultas de la lista se ejecuta en la cola correspondiente. No hay un límite establecido para el número de grupos de consultas que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de una consulta a un grupo de consultas](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group). ## Caracteres comodín Si los comodines están habilitados en la configuración de la cola de WLM, puede asignar grupos de usuarios y de consultas a una cola individualmente o utilizando los comodines de estilo shell Unix. La coincidencia de patrones no distingue entre mayúsculas y minúsculas. Por ejemplo, el comodín «\$1» coincide con cualquier número de caracteres. Así, si añade `dba_*` a la lista de grupos de usuario para una cola, cualquier consulta ejecutada por un usuario que pertenece a un grupo con un nombre que comienza por `dba_` se asigna a esa cola. Algunos ejemplos son `dba_admin` o `DBA_primary`. El comodín «?» coincide con cualquier carácter individual. Así, si la cola incluye el grupo de usuarios `dba?1`, entonces los grupos de usuarios denominados `dba11` y `dba21` coinciden, pero `dba12` no coincide. Los comodines se encuentran desactivados de forma predeterminada. ## Porcentaje de memoria de WLM por utilizar En una configuración de WLM automática, el porcentaje de memoria se establece en **auto**. Para obtener más información, consulte [Implementación de WLM automática](automatic-wlm.md). En una configuración de WLM manual, para especificar la cantidad de memoria disponible que se asigna a una consulta, puede establecer el parámetro `WLM Memory Percent to Use`. De forma predeterminada, a cada cola definida por el usuario se le asigna una parte igual de la memoria que esté disponible para consultas definidas por el usuario. Por ejemplo, si tiene cuatro colas definidas por el usuario, a cada cola se le asigna un 25 por ciento de la memoria disponible. La cola de superusuario tiene su propia memoria asignada y no puede modificarse. Para cambiar la asignación, asigne un porcentaje entero de memoria a cada cola, hasta llegar a un total de 100 por ciento. Amazon Redshift administra la memoria que ha quedado sin asignar, la cual se puede asignar de forma temporal a una cola si esta solicita memoria adicional para el procesamiento. Por ejemplo, si configura cuatro colas, puede asignar la memoria de la siguiente forma: 20 por ciento, 30 por ciento, 15 por ciento, 15 por ciento. El 20 por ciento restante queda sin asignar y lo administra el servicio. ## Tiempo de espera de WLM El tiempo de espera de WLM (`max_execution_time`) no está disponible. En su lugar, cree una regla de monitorización de consultas (QMR) utilizando `query_execution_time` para limitar el tiempo de ejecución transcurrido de una consulta. Para obtener más información, consulte [Reglas de monitoreo de consultas de WLM](cm-c-wlm-query-monitoring-rules.md). Para limitar la cantidad de tiempo que las consultas de una determinada cola de WLM tienen permitido utilizar, puede establecer el valor de tiempo de espera de WLM para cada cola. El parámetro de tiempo de espera especifica la cantidad de tiempo, en milisegundos, que Amazon Redshift espera para que se ejecute una consulta antes de cancelarla o saltarla. El tiempo de espera se basa en el tiempo de ejecución de consultas y no incluye el tiempo de espera empleado en una cola. WLM intenta transferir las instrucciones [CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) y las consultas de solo lectura, como las instrucciones SELECT. Las consultas que no se pueden transferir se cancelan. Para obtener más información, consulte [Salto de cola de consultas de WLM](wlm-queue-hopping.md). El tiempo de espera de WLM no aplica a una consulta que haya alcanzado el estado de devolución. Para ver el estado de una consulta, consulte la tabla de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). Las instrucciones COPY y las operaciones de mantenimiento, como ALTER, ANALYZE y VACUUM, no están sujetas al tiempo de espera de WLM. La función de tiempo de espera de WLM es similar al parámetro de configuración [statement\$1timeout](r_statement_timeout.md). La diferencia es que, en los casos que el parámetro de configuración `statement_timeout` aplica a todo el clúster, el tiempo de espera de WLM es específico de una cola individual en la configuración de WLM. Si también se especifica [statement\$1timeout](r_statement_timeout.md), se utiliza el statement\$1timeout y el tiempo de espera de WLM (max\$1execution\$1time) inferiores. ## Reglas de monitorización de consultas Las reglas de monitorización de consultas definen los límites de rendimiento basados en métricas para las colas de WLM y especifican la acción que se debe realizar cuando una consulta va más allá de esos límites. Por ejemplo, para una cola dedicada a consultas de ejecución corta, puede crear una regla que cancele las consultas que se ejecuten durante más de 60 segundos. Para hacer un seguimiento de las consultas mal diseñadas, puede disponer de otra regla que registre las consultas que contienen bucles anidados. Para obtener más información, consulte [Reglas de monitoreo de consultas de WLM](cm-c-wlm-query-monitoring-rules.md). # Salto de cola de consultas de WLM Con Amazon Redshift, puede administrar la simultaneidad de la carga de trabajo y la asignación de recursos al habilitar el salto de cola de consultas de WLM (Administración de la carga de trabajo). Esta característica permite que las consultas “salten” temporalmente de una cola asignada a una cola de mayor prioridad cuando hay recursos disponibles, lo que mejora el rendimiento general de las consultas y la utilización del sistema. En las siguientes secciones se proporcionan instrucciones detalladas sobre la configuración y el uso de los saltos de cola de consultas de WLM en Amazon Redshift. Una consulta puede saltarse porque se ha agotado el [tiempo de espera de WLM](cm-c-defining-query-queues.md#wlm-timeout) o por una [acción de salto de una regla de monitoreo de consultas (QMR)](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules). Solo puede transferir consultas en una configuración de WLM manual. Cuando se salta una consulta, WLM intenta direccionarla a la siguiente cola coincidente en función de las [reglas de asignación de colas de WLM](cm-c-wlm-queue-assignment-rules.md). Si la consulta no coincide con ninguna otra definición de cola, se cancelará. No se asigna a la cola predeterminada. ## Acciones de tiempo de espera de WLM En la siguiente tabla, se resume el comportamiento de diferentes tipos de consulta con un tiempo de espera de WLM. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/wlm-queue-hopping.html) ## Salto de cola por un tiempo de espera de WLM WLM transfiere los siguientes tipos de consultas cuando se agota el tiempo de espera: + Consultas de solo lectura, como las instrucciones SELECT, cuando tienen el estado de WLM `running`. Para encontrar el estado de WLM de una consulta, vea la columna STATE en la tabla de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). + Instrucciones CREATE TABLE AS (CTAS). El salto de colas de WLM es compatible con instrucciones CTAS definidas por el usuario y generadas por el sistema. + Instrucciones SELECT INTO Las consultas que no están sujetas al tiempo de espera de WLM siguen ejecutándose en la cola original hasta su finalización. Los siguientes tipos de consultas no están sujetos al tiempo de espera de WLM: + Instrucciones COPY. + Operaciones de mantenimiento, como ALTER, ANALYZE y VACUUM + Consultas de solo lectura, como instrucciones SELECT, que han alcanzado el estado de WLM `returning`. Para encontrar el estado de WLM de una consulta, vea la columna STATE en la tabla de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). Las consultas que no pueden transferirse al agotar el tiempo de espera de WLM se cancelan. Los siguientes tipos de consultas no pueden transferirse al agotarse el tiempo de espera de WLM: + Instrucciones INSERT, UPDATE y DELETE. + Instrucciones UNLOAD. + Funciones definidas por el usuario (UDF). ## Consultas reasignadas o reiniciadas por un tiempo de espera de WLM. Cuando se transfiere una consulta y no se encuentra ninguna cola que coincida, la consulta se cancela. Cuando se transfiere una consulta y se encuentra una cola coincidente, WLM intenta reasignar la consulta a esta nueva cola. Si la consulta no se puede reasignar, se reinicia en la nueva cola, tal y como se describe a continuación. Una consulta solo puede reasignarse si se dan todas las condiciones siguientes: + Se encuentra una cola coincidente. + La nueva cola tiene suficientes slots libres para ejecutar la consulta. Una consulta puede necesitar varios slots si el parámetro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) se ha establecido en un valor mayor que 1. + La nueva consulta tiene al menos tanta memoria disponible como la que utiliza actualmente. Si la consulta se reasigna, sigue ejecutándose en la nueva cola. Los resultados intermedios se conservan, por lo que el efecto en el tiempo total de ejecución es mínimo. Si la consulta no se puede reasignar, se cancela y se reinicia en la nueva cola. Los resultados intermedios se eliminan. La consulta espera en la cola y, cuando hay suficientes slots disponibles, comienza a ejecutarse. ## Acciones de transferencia de QMR En la siguiente tabla, se resume el comportamiento de diferentes tipos de consulta con una acción de transferencia de QMR. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/wlm-queue-hopping.html) Para saber si una consulta transferida por QMR se ha reasignado, reiniciado o cancelado, consulte la tabla de registro del sistema [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md). ## Consultas reasignadas o reiniciadas por una acción de salto de QMR Cuando se transfiere una consulta y no se encuentra ninguna cola que coincida, la consulta se cancela. Cuando se transfiere una consulta y se encuentra una cola coincidente, WLM intenta reasignar la consulta a esta nueva cola. Si una consulta no se puede reasignar, se reinicia en la nueva cola o sigue ejecutándose en la cola original, tal y como se describe a continuación. Una consulta solo puede reasignarse si se dan todas las condiciones siguientes: + Se encuentra una cola coincidente. + La nueva cola tiene suficientes slots libres para ejecutar la consulta. Una consulta puede necesitar varios slots si el parámetro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) se ha establecido en un valor mayor que 1. + La nueva consulta tiene al menos tanta memoria disponible como la que utiliza actualmente. Si la consulta se reasigna, sigue ejecutándose en la nueva cola. Los resultados intermedios se conservan, por lo que el efecto en el tiempo total de ejecución es mínimo. Si una consulta no se puede reasignar, se reinicia o sigue ejecutándose en la cola original. Cuando una consulta se reinicia, se cancela y se reinicia en la nueva cola. Los resultados intermedios se eliminan. La consulta espera en la cola y, cuando hay suficientes slots disponibles, comienza a ejecutarse. # Tutorial: Configuración de colas de Administración de carga de trabajo (WLM) manual Con Amazon Redshift, puede configurar colas de administración manual de cargas de trabajo (WLM) para priorizar y asignar recursos a distintos tipos de consultas y usuarios. Las colas de WLM manuales le permiten controlar la configuración de memoria y simultaneidad de colas específicas, lo que garantiza que las cargas de trabajo críticas reciban los recursos necesarios y, al mismo tiempo, evita que las consultas de baja prioridad monopolicen el sistema. En las siguientes secciones, se le guiará a través del proceso de creación y configuración de colas de WLM manuales en Amazon Redshift para cumplir con los requisitos de administración de la carga de trabajo. ## Descripción general Recomendamos configurar la administración de cargas de trabajo (WLM) automática en Amazon Redshift. Para obtener más información acerca de la WLM automática, consulte [Administración de la carga de trabajo](cm-c-implementing-workload-management.md). No obstante, si necesita múltiples colas de WLM, en este tutorial, se detalla el proceso de configuración de la administración de cargas de trabajo (WLM) manual en Amazon Redshift. Al configurar WLM manual, puede mejorar el rendimiento de consultas y la asignación de recursos en el clúster. Amazon Redshift dirige las consultas de usuarios a las colas para su procesamiento. WLM define el modo en que esas consultas se dirigen a las colas. De forma predeterminada, Amazon Redshift tiene dos colas disponibles para consultas: una para superusuarios y una para usuarios. La cola de superusuario no se puede configurar y solo puede procesar una consulta a la vez. Debe reservar esta cola únicamente para solucionar problemas. La cola de usuarios puede procesar hasta cinco consultas a la vez, pero, si lo necesita, puede configurar esto modificando el nivel de simultaneidad de la cola. Cuando tiene varios usuarios ejecutando consultas en la base de datos, tal vez otra configuración le resulte más eficaz. Por ejemplo, si algunos usuarios ejecutan operaciones que consumen muchos recursos, como VACUUM, esto puede tener un impacto negativo en las consultas que menos consumen, como informes. Podría plantearse agregar colas adicionales y configurarlas para cargas de trabajo diferentes. **Tiempo estimado**: 75 minutos **Costo estimado:** 50 céntimos ### Requisitos previos Necesita un clúster de Amazon Redshift, la base de datos de ejemplo TICKIT y la herramienta de cliente Amazon Redshift RSQL. Si todavía no tiene estos elementos configurados, vaya a [Guía de introducción a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) y a [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html). ### Secciones + [Sección 1: Comportamiento del procesamiento de la cola predeterminada](#tutorial-wlm-understanding-default-processing) + [Sección 2: Modificación de la configuración de la cola de consultas de WLM](#tutorial-wlm-modifying-wlm-configuration) + [Sección 3: Direccionamiento de consultas a las colas en función de los grupos de usuarios y de consultas](#tutorial-wlm-routing-queries-to-queues) + [Sección 4: Utilización de wlm\$1query\$1slot\$1count para anular de forma temporal el nivel de simultaneidad en una cola](#tutorial-wlm-query-slot-count) + [Sección 5: Limpieza de los recursos](#tutorial-wlm-cleaning-up-resources) ## Sección 1: Comportamiento del procesamiento de la cola predeterminada Antes de comenzar a configurar la WLM manual, es útil entender el comportamiento predeterminado del procesamiento de las colas en Amazon Redshift. En esta sección, crea dos vistas de bases de datos que devuelvan la información de varias tablas de sistema. Luego, ejecuta algunas consultas de prueba para ver cómo se dirigen las consultas de forma predeterminada. Para obtener más información acerca de las tablas de sistema, consulte [Referencia de las tablas y vistas de sistema](cm_chap_system-tables.md). ### Paso 1: Creación de la vista WLM\$1QUEUE\$1STATE\$1VW En este paso, creará una vista denominada WLM\$1QUEUE\$1STATE\$1VW. Esta vista devuelve la información de las siguientes tablas de sistema. + [STV\$1WLM\$1CLASSIFICATION\$1CONFIG](r_STV_WLM_CLASSIFICATION_CONFIG.md) + [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md) + [STV\$1WLM\$1SERVICE\$1CLASS\$1STATE](r_STV_WLM_SERVICE_CLASS_STATE.md) Esta vista se utiliza en todo el tutorial para supervisar lo que les ocurre a las colas después de modificar la configuración de WLM. En la siguiente tabla se describen los datos que devuelve la vista WLM\$1QUEUE\$1STATE\$1VW. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/tutorial-configuring-workload-management.html) #### Creación de la vista WLM\$1QUEUE\$1STATE\$1VW 1. Abra [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) y conéctese a la base de datos de ejemplo de TICKIT. Si no dispone de esta base de datos, consulte [Requisitos previos](#tutorial-wlm-prereq). 1. Ejecute la siguiente consulta para crear la vista WLM\$1QUEUE\$1STATE\$1VW. ``` create view WLM_QUEUE_STATE_VW as select (config.service_class-5) as queue , trim (class.condition) as description , config.num_query_tasks as slots , config.query_working_mem as mem , config.max_execution_time as max_time , config.user_group_wild_card as "user_*" , config.query_group_wild_card as "query_*" , state.num_queued_queries queued , state.num_executing_queries executing , state.num_executed_queries executed from STV_WLM_CLASSIFICATION_CONFIG class, STV_WLM_SERVICE_CLASS_CONFIG config, STV_WLM_SERVICE_CLASS_STATE state where class.action_service_class = config.service_class and class.action_service_class = state.service_class and config.service_class > 4 order by config.service_class; ``` 1. Ejecute la siguiente consulta para ver la información que contiene la vista. ``` select * from wlm_queue_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 1 | 160 ``` ### Paso 2: Creación de la vista WLM\$1QUERY\$1STATE\$1VW En este paso, crea una vista denominada WLM\$1QUERY\$1STATE\$1VW. Esta vista devuelve la información de la tabla de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). Esta vista se utiliza en todo el tutorial para supervisar las consultas que están en ejecución. En la siguiente tabla se describen los datos que devuelve la vista WLM\$1QUERY\$1STATE\$1VW. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/tutorial-configuring-workload-management.html) #### Creación de la vista WLM\$1QUERY\$1STATE\$1VW 1. En RSQL, ejecute la siguiente consulta para crear la vista WLM\$1QUERY\$1STATE\$1VW. ``` create view WLM_QUERY_STATE_VW as select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time from stv_wlm_query_state; ``` 1. Ejecute la siguiente consulta para ver la información que contiene la vista. ``` select * from wlm_query_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1249 | 1 | 1 | 2014-09-24 22:19:16 | Executing | 0 | 516 ``` ### Paso 3: Ejecución de consultas de prueba En este paso, ejecuta consultas desde varias conexiones en RSQL y revisa las tablas de sistema para determinar cómo se dirigieron las consultas para su procesamiento. Para este paso, necesita tener dos ventanas RSQL abiertas: + En la ventana RSQL 1, se ejecutan consultas que monitoreen el estado de las colas y consultas que utilicen las vistas ya creadas en este tutorial. + En la ventana RSQL 2, se pueden ejecutar consultas de ejecución prolongada para cambiar los resultados que se encuentren en la ventana 1 de RSQL. #### Ejecución de las consultas de prueba 1. Abra las dos ventanas RSQL. Si ya tiene una ventana abierta, solo necesita abrir una segunda. Puede utilizar la misma cuenta de usuario para ambas conexiones. 1. En la ventana RSQL 1, ejecute la siguiente consulta. ``` select * from wlm_query_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1258 | 1 | 1 | 2014-09-24 22:21:03 | Executing | 0 | 549 ``` Esta consulta devuelve un resultado autorreferencial. La consulta que se encuentra en ejecución es la instrucción SELECT de esta vista. Una consulta en esta vista siempre devuelve como mínimo un resultado. Compara este resultado con el resultado que se produzca después de comenzar la consulta de ejecución prolongada, en el siguiente paso. 1. En la ventana RSQL 2, ejecute una consulta desde la base de datos de ejemplo TICKIT. Esta consulta se debe ejecutar por un minuto aproximadamente, de modo que tenga tiempo para explorar los resultados de las vistas WLM\$1QUEUE\$1STATE\$1VW y WLM\$1QUERY\$1STATE\$1VW que creó antes. En algunos casos, es posible que encuentre que la consulta no se ejecuta durante el tiempo necesario para consultar ambas vistas. En estos casos, puede aumentar el valor del filtro en `l.listid ` para que se ejecute durante más tiempo. **nota** Para reducir el tiempo de ejecución de las consultas y mejorar el rendimiento del sistema, Amazon Redshift almacena en caché los resultados de ciertos tipos de consultas en la memoria del nodo principal. Si se ha habilitado el almacenamiento en caché de los resultados, las consultas posteriores se ejecutarán mucho más rápido. Para evitar que la consulta se ejecute con demasiada rapidez, deshabilite el almacenamiento en caché de los resultados para la sesión actual. Para deshabilitar el almacenamiento en caché de los resultados para la sesión actual, establezca el parámetro [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) en `off`, tal y como se muestra a continuación. ``` set enable_result_cache_for_session to off; ``` En la ventana RSQL 2, ejecute la siguiente consulta. ``` select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000; ``` 1. En la ventana RSQL 1, consulte WLM\$1QUEUE\$1STATE\$1VW y WLM\$1QUERY\$1STATE\$1VW y compare los resultados con los resultados anteriores. ``` select * from wlm_queue_state_vw; select * from wlm_query_state_vw; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 2 | 163 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1267 | 1 | 1 | 2014-09-24 22:22:30 | Executing | 0 | 684 1265 | 1 | 1 | 2014-09-24 22:22:36 | Executing | 0 | 4080859 ``` Observe las siguientes diferencias entre las consultas anteriores y los resultados de este paso: + Ahora existen dos filas en WLM\$1QUERY\$1STATE\$1VW. Un resultado es la consulta autorreferencial por la ejecución de una operación SELECT en esta vista. El segundo resultado es la consulta de ejecución prolongada del paso anterior. + La columna executing en WLM\$1QUEUE\$1STATE\$1VW aumentó de 1 a 2. Esta entrada de la columna significa que hay dos consultas en ejecución en la cola. + La columna executed se incrementa cada vez que ejecute una consulta en la cola. La vista WLM\$1QUEUE\$1STATE\$1VW es útil para obtener una vista general de las colas y saber cuántas consultas se están procesando en cada cola. La vista WLM\$1QUERY\$1STATE\$1VW es útil para obtener una vista más detallada de las consultas individuales que se están ejecutando. ## Sección 2: Modificación de la configuración de la cola de consultas de WLM Ahora que ya conoce el funcionamiento predeterminado de las colas, puede aprender a configurar las colas de consultas con la WLM manual. En esta sección, crea y configura un nuevo grupo de parámetros para el clúster. Va a crear dos colas de usuario adicionales y las va a configurar para que acepten consultas en función de las etiquetas del grupo de consultas o del grupo de usuarios de las consultas. Cualquier consulta que no se dirija a una de estas dos colas se dirigirá a la cola predeterminada en tiempo de ejecución. **Para crear una configuración manual de WLM en un grupo de parámetros** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. En el menú de navegación, elija **Configurations** (Configuraciones) y, a continuación, elija **Workload management (Administración de la carga de trabajo)** para mostrar la página de **Workload management (Administración de la carga de trabajo)**. 1. Seleccione **Create (Crear)** para mostrar la ventana de **Create parameter group (Crear grupo de parámetros)**. 1. Introduzca **WLMTutorial** en el **Nombre del grupo de parámetros** y en **Descripción**. A continuación, elija **Crear** para crear el grupo de parámetros. **nota** El **nombre del grupo de parámetros** se convierte a un formato de todo en minúsculas cuando se crea. 1. En la página de **Workload management (Administración de la carga de trabajo)**, seleccione el grupo de parámetros **wlmtutorial** para mostrar la página de detalles con pestañas para **Parameters (Parámetros)** y **Workload management (Administración de la carga de trabajo)**. 1. Asegúrese de que está en la pestaña **Workload management (Administración de la carga de trabajo)** y luego seleccione **Switch WLM mode (Cambiar modo de WLM)** para mostrar la ventana de **Concurrency settings (Configuración de concurrencia)**. 1. Seleccione **WLM manual** y luego **Save (Guardar)** para cambiar al WLM manual. 1. Seleccione **Edit workload queues (Editar colas de carga de trabajo)**. 1. Seleccione dos veces **Add queue (Agregar cola)** para agregar dos colas. Ahora hay tres colas: **Cola 1**, **Cola 2** y **Cola predeterminada**. 1. Introduzca información para cada cola como se indica a continuación: + En la **Cola 1**, introduzca **30** para **Memory (Memoria) (%)**, **2** para **Concurrency on main (Concurrencia en principal)** y **test** para **Query groups (Grupos de consulta)**. No cambie los demás valores predeterminados. + En la **Cola 2**, introduzca **40** para **Memory (Memoria) (%)**, **3** para **Concurrency on main (Concurrencia en principal)** y **admin** para **User groups (Grupos de usuario)**. No cambie los demás valores predeterminados. + Establezca el valor de **Simultaneidad en el principal** de la cola predeterminada en un valor mayor o igual a 1. No realice ningún cambio en **Cola predeterminada**. WLM asigna la memoria sin asignar a la cola predeterminada. 1. Seleccione **Save** (Guardar) para guardar las configuraciones. A continuación, asocie el grupo de parámetros que tiene la configuración manual de WLM con un clúster. **Para asociar un grupo de parámetros que tenga una configuración manual de WLM con un clúster** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. En el menú de navegación, elija **Clusters** (Clústeres) y, a continuación, elija **Clusters** (Clústeres) para mostrar una lista de los clústeres. 1. Elija el clúster, como `examplecluster`, para mostrar los detalles del clúster. A continuación, elija la pestaña **Properties** (Propiedades) para mostrar las propiedades de ese clúster. 1. En la sección **Database configurations** (Configuración de las bases de datos), elija **Edit** (Editar) y **Edit parameter group** (Editar grupo de parámetros) para mostrar la ventana de grupos de parámetros. 1. En **Parameter groups** (Grupos de parámetros), elija el grupo de parámetros **wlmtutorial** creado anteriormente. 1. Elija **Save changes** (Guardar cambios) para asociar el grupo de parámetros. El clúster se modifica con el grupo de parámetros cambiado. No obstante, tendrá que reiniciar el cluster para que se apliquen los cambios en la base de datos. 1. Elija su clúster y luego elija **Reboot** (Reiniciar) en **Actions** (Acciones). Una vez que se reinicie el clúster, volverá al estado **Available (Disponible)**. ## Sección 3: Direccionamiento de consultas a las colas en función de los grupos de usuarios y de consultas Ahora tiene el clúster asociado un grupo de parámetros nuevo y ha configurado WLM. A continuación, ejecute algunas consultas para ver cómo Amazon Redshift dirige las consultas a las colas para su procesamiento. ### Paso 1: Vista de la configuración de la cola de consultas en la base de datos Primero, verifique que la base de datos tenga la configuración WLM que espera. #### Para ver la configuración de la cola de consultas 1. Abra RSQL y ejecute la siguiente consulta. La consulta utiliza la vista WLM\$1QUEUE\$1STATE\$1VW que el usuario creó en [Paso 1: Creación de la vista WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Si ya tenía una sesión conectada a la base de datos antes de reiniciar el clúster, deberá volver a conectarla. ``` select * from wlm_queue_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0 ``` Compare estos resultados con los resultados recibidos en [Paso 1: Creación de la vista WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Observe que ahora hay dos colas adicionales. La cola 1 ahora es la cola para el grupo de consultas de prueba y la cola 2 es la cola para el grupo del usuario administrador. La cola 3 ahora es la cola predeterminada. La última cola de la lista siempre es la cola predeterminada. Esa es la cola a la que se dirigen las consultas de forma predeterminada si no se especifica ningún grupo de usuarios o de consultas en una consulta. 1. Ejecute la siguiente consulta para confirmar que la consulta ahora se ejecuta en la cola 3. ``` select * from wlm_query_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2144 | 3 | 1 | 2014-09-24 23:49:59 | Executing | 0 | 550430 ``` ### Paso 2: Ejecución de una consulta mediante la cola de grupo de consultas #### Para ejecutar una consulta mediante la cola de grupo de consultas 1. Ejecute la siguiente consulta para dirigirla al grupo de consultas `test`. ``` set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. Desde la otra ventana RSQL, ejecute la siguiente consulta. ``` select * from wlm_query_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2168 | 1 | 1 | 2014-09-24 23:54:18 | Executing | 0 | 6343309 2170 | 3 | 1 | 2014-09-24 23:54:24 | Executing | 0 | 847 ``` La consulta se dirigió al grupo de consultas de prueba, que ahora es la cola 1. 1. Seleccione todos los elementos de la vista de estado de la cola. ``` select * from wlm_queue_state_vw; ``` Se ve un resultado similar al siguiente. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0 ``` 1. Ahora, restablezca el grupo de consultas y vuelva a ejecutar la consulta larga: ``` reset query_group; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. Ejecute las consultas en las vistas para ver los resultados. ``` select * from wlm_queue_state_vw; select * from wlm_query_state_vw; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 2 | 5 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2186 | 3 | 1 | 2014-09-24 23:57:52 | Executing | 0 | 649 2184 | 3 | 1 | 2014-09-24 23:57:48 | Executing | 0 | 4137349 ``` El resultado debe ser que la consulta ahora se ejecute en la cola 3 nuevamente. ### Paso 3: Creación de un usuario y un grupo de base de datos Antes de poder ejecutar cualquier consulta en esta cola, debe crear el grupo de usuarios en la base de datos y agregar un usuario al grupo. A continuación, inicie sesión con RSQL con las nuevas credenciales de usuario y ejecute las consultas. Debe ejecutar las consultas como superusuario, como por ejemplo, usuario administrador, para crear usuarios de bases de datos. #### Para crear un usuario y un grupo de usuarios de base de datos nuevos 1. En la base de datos, cree un usuario de base de datos nuevo denominado `adminwlm` mediante la ejecución del siguiente comando en una ventana RSQL. ``` create user adminwlm createuser password '123Admin'; ``` 1. Luego, ejecute los siguientes comandos para crear un nuevo grupo de usuarios y agregue el nuevo usuario `adminwlm` a él. ``` create group admin; alter group admin add user adminwlm; ``` ### Paso 4: Ejecución de una consulta mediante la cola de grupo de usuarios A continuación, ejecuta una consulta y la dirige a la cola de grupo de usuarios. Esto se hace cuando desea dirigir la consulta a una cola que esté configurada para administrar el tipo de consulta que desea ejecutar. #### Para ejecutar una consulta mediante la cola de grupo de usuarios 1. En la ventana RSQL 2, ejecute las siguientes consultas para cambiar a la cuenta `adminwlm` y ejecute una consulta como ese usuario. ``` set session authorization 'adminwlm'; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. En la ventana RSQL 1, ejecute la siguiente consulta para ver la cola de consultas a la que se dirigen las consultas. ``` select * from wlm_query_state_vw; select * from wlm_queue_state_vw; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 8 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2202 | 2 | 1 | 2014-09-25 00:01:38 | Executing | 0 | 4885796 2204 | 3 | 1 | 2014-09-25 00:01:43 | Executing | 0 | 650 ``` La cola en la que se ejecuta esta consulta es la cola 2, la cola de usuario `admin`. Cada vez que inicie sesión como este usuario y ejecute consultas, estas se ejecutan en la cola 2 a menos que especifique otro grupo de consultas para utilizar. La cola elegida depende de las reglas de asignación de colas. Para obtener más información, consulte [Reglas de asignación de colas de WLM](cm-c-wlm-queue-assignment-rules.md). 1. Ahora ejecute la siguiente consulta desde la ventana RSQL 2. ``` set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. En la ventana RSQL 1, ejecute la siguiente consulta para ver la cola de consultas a la que se dirigen las consultas. ``` select * from wlm_queue_state_vw; select * from wlm_query_state_vw; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 1 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 10 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2218 | 1 | 1 | 2014-09-25 00:04:30 | Executing | 0 | 4819666 2220 | 3 | 1 | 2014-09-25 00:04:35 | Executing | 0 | 685 ``` 1. Cuando haya terminado, restablezca el grupo de consultas. ``` reset query_group; ``` ## Sección 4: Utilización de wlm\$1query\$1slot\$1count para anular de forma temporal el nivel de simultaneidad en una cola En ocasiones, los usuarios pueden necesitar de forma temporal más recursos para una consulta en particular. De ser así, pueden utilizar la opción de configuración wlm\$1query\$1slot\$1count para anular temporalmente la forma en la que se asignan los slots en una cola de consultas. Los *slots* son unidades de memoria y CPU que se utilizan para procesar consultas. Puede anular el número de slots cuando tiene consultas ocasionales que consumen una gran cantidad de recursos del clúster, como cuando realiza una operación VACUUM en la base de datos. Es posible que se encuentre con que los usuarios necesitan con frecuencia establecer para determinados tipos de consulta. Si es así, plantéese ajustar la configuración de WLM y proporcionar a los usuarios una cola que se adapte mejor a las necesidades de sus consultas. Para obtener más información acerca de la anulación temporal del nivel de simultaneidad utilizando el número de slots, consulte [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md). ### Paso 1: Anulación del nivel de simultaneidad mediante wlm\$1query\$1slot\$1count Para los fines de este tutorial, ejecutamos la misma consulta de ejecución prolongada SELECT. La ejecutamos como el usuario `adminwlm` con wlm\$1query\$1slot\$1count para aumentar el número de slots disponibles para la consulta. #### Para anular el nivel de simultaneidad mediante wlm\$1query\$1slot\$1count 1. Aumente el límite en la consulta para asegurarse de que dispone del tiempo suficiente para consultar la vista WLM\$1QUERY\$1STATE\$1VW y ver un resultado. ``` set wlm_query_slot_count to 3; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. Ahora, la consulta WLM\$1QUERY\$1STATE\$1VW utiliza el usuario administrador para ver cómo se ejecuta la consulta. ``` select * from wlm_query_state_vw; ``` A continuación se muestra un resultado de ejemplo. ``` query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2240 | 2 | 1 | 2014-09-25 00:08:45 | Executing | 0 | 3731414 2242 | 3 | 1 | 2014-09-25 00:08:49 | Executing | 0 | 596 ``` Observe que el número de slots para la consulta es 3. Este número significa que la consulta está utilizando los tres slots para procesarse, lo que lleva a la asignación de todos los recursos de la cola a esa consulta. 1. Ahora, ejecute la siguiente consulta. ``` select * from WLM_QUEUE_STATE_VW; ``` A continuación se muestra un resultado de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 4 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 25 ``` La opción de configuración wlm\$1query\$1slot\$1count es válida solo para la sesión actual. Si esa sesión expira u otro usuario ejecuta una consulta, se utiliza la configuración de WLM. 1. Restablezca el número de slots y vuelva a ejecutar la prueba. ``` reset wlm_query_slot_count; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 2 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 14 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2260 | 2 | 1 | 2014-09-25 00:12:11 | Executing | 0 | 4042618 2262 | 3 | 1 | 2014-09-25 00:12:15 | Executing | 0 | 680 ``` ### Paso 2: Ejecución de consultas de sesiones diferentes A continuación, ejecute consultas de sesiones diferentes. #### Para ejecutar consultas de sesiones diferentes 1. En las ventanas RSQL 1 y 2, ejecute lo siguiente para utilizar el grupo de consultas de prueba. ``` set query_group to test; ``` 1. En la ventana RSQL 1, ejecute la siguiente consulta de ejecución prolongada. ``` select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. Mientras se ejecuta la consulta de ejecución prolongada en la ventana RSQL 1, ejecute lo siguiente. Estos comandos aumentan el recuento de slots para usar todos los slots para la cola y empezar a ejecutar la consulta de ejecución prolongada a continuación. ``` set wlm_query_slot_count to 2; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; ``` 1. Abra una tercera ventana RSQL y consulte las vistas para ver los resultados. ``` select * from wlm_queue_state_vw; select * from wlm_query_state_vw; ``` A continuación se incluyen resultados de ejemplo. ``` query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 1 | 1 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 18 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+---------------+------------+----------- 2286 | 1 | 2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950 | 0 2282 | 1 | 1 | 2014-09-25 00:16:33 | Executing | 0 | 19335850 2288 | 3 | 1 | 2014-09-25 00:16:52 | Executing | 0 | 666 ``` Observe que la primera consulta utiliza uno de los slots asignados a la cola 1 para ejecutar la consulta. Observe, además, que hay un consulta esperando en la cola (donde `queued` es `1` y `state` es `QueuedWaiting`). Una vez que se completa la primera consulta, la segunda comienza a ejecutarse. Esta ejecución ocurre porque ambas consultas se dirigen al grupo de consultas `test` y la segunda consulta debe esperar por la cantidad de slots suficientes para comenzar a procesarse. ## Sección 5: Limpieza de los recursos El clúster seguirá acumulando cargos mientras esté en ejecución. Una vez que haya completado este tutorial, restablezca el entorno al estado anterior y, para ello, siga los pasos de [Búsqueda de recursos adicionales y restablecimiento del entorno](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) en la *Guía de introducción a Amazon Redshift*. Para obtener más información acerca de WLM, consulte [Administración de la carga de trabajo](cm-c-implementing-workload-management.md).