¿Cómo uso y administro la asignación de memoria WLM de Amazon Redshift?

Descripción corta

Utiliza uno de los métodos siguientes para configurar WLM a fin de administrar los recursos de manera eficaz:

• WLM automática: Amazon Redshift administra el nivel de simultaneidad de las colas y la asignación de memoria para cada consulta enviada. La consulta distribuida permite definir la prioridad de consulta de la carga de trabajo o de los usuarios para cada una de las colas de consultas.
• WLM manual: Tienes más control sobre el nivel de simultaneidad y la asignación de memoria a las colas. Como resultado, las consultas con un mayor consumo de recursos pueden ejecutarse en colas con una mayor asignación de recursos.

Se recomienda utilizar el WLM automático, ya que utiliza el machine learning para predecir la cantidad de memoria necesaria para asignar las consultas. Si utilizas un WLM manual y deseas migrar a un WLM automático, consulta Migración del WLM manual al WLM automático.

Nota: Para definir los límites de rendimiento basados en métricas, utiliza una regla de supervisión de consultas (QMR) con la configuración de WLM.

Resolución

Para comprobar el nivel de simultaneidad y la asignación de WLM a las colas, realiza las siguientes acciones:

• Comprueba la configuración actual de WLM de tu clúster de Amazon Redshift.
• Crea una configuración de WLM de prueba y especifica la distribución y el nivel de simultaneidad de la cola de consultas.
• (Opcional) Si utilizas un WLM manual, determina cómo se distribuye la memoria entre los recuentos de ranuras.

Comprobación de la configuración actual del WLM y el uso de memoria

Utiliza la tabla STV_WLM_SERVICE_CLASS_CONFIG para comprobar la configuración actual de WLM de tu clúster de Amazon Redshift.

Ejemplo de configuración de WLM:

[
  {
    "query_concurrency": 2,
    "memory_percent_to_use": 30,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [
      "user_group1"
    ],
    "user_group_wild_card": 0,
    "rules": [
      {
        "rule_name": "BlockstoDiskSpill",
        "predicate": [
          {
            "metric_name": "query_temp_blocks_to_disk",
            "operator": ">",
            "value": 50
          }
        ],
        "action": "abort"
      }
    ]
  },
  {
    "query_concurrency": 5,
    "memory_percent_to_use": 40,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [
      "user_group2"
    ],
    "user_group_wild_card": 0
  },
  {
    "query_concurrency": 5,
    "memory_percent_to_use": 10,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [],
    "user_group_wild_card": 0,
    "rules": [
      {
        "rule_name": "abort_query",
        "predicate": [
          {
            "metric_name": "scan_row_count",
            "operator": ">",
            "value": 1000
          }
        ],
        "action": "abort"
      }
    ]
  },
  {
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [],
    "user_group_wild_card": 0,
    "auto_wlm": false
  },
  {
    "short_query_queue": false
  }
]

Nota: El ejemplo anterior de configuración de WLM está en formato JSON y utiliza el QMR, cola 1. En el ejemplo, memory_percent_to_use es la cantidad real de memoria de trabajo que se asigna a la clase de servicio.

Amazon Redshift asigna memoria del grupo de recursos compartidos de tu clúster. La cola 1 tiene una asignación de memoria del 30 % que se divide en dos ranuras iguales porque la simultaneidad se establece en 2. Cada ranura recibe una parte igual del 15 % de la asignación de memoria actual.

Queue2 tiene una asignación de memoria del 40 % que se divide en cinco ranuras iguales porque la simultaneidad se establece en 5. Cada ranura recibe un 8 % igual de la asignación de memoria. La cola predeterminada usa el 10 % de la asignación de memoria con un nivel de simultaneidad de colas de 5.

Utiliza la siguiente consulta para comprobar la configuración de la clase de servicio:

select rtrim(name) as name,
num_query_tasks as slots,
query_working_mem as mem,
max_execution_time as max_time,
user_group_wild_card as user_wildcard,
query_group_wild_card as query_wildcard
from stv_wlm_service_class_config
where service_class > 4;

Resultado de ejemplo:

                        name                        | slots | mem | max_time | user_wildcard | query_wildcard
----------------------------------------------------+-------+-----+----------+---------------+----------------
 Service class for super user                       |     1 | 297 |        0 | false         | false
 Queue 1                                            |     2 | 522 |        0 | false         | false
 Queue 2                                            |     5 | 278 |        0 | false         | false
 Default queue                                      |     5 |  69 |        0 | false         | false
 Service class for vacuum/analyze                   |     0 |   0 |        0 | false         | false

La cola 1 tiene un número de ranuras de 2 y la memoria asignada para cada ranura o nodo es de 522 MB. La asignación de memoria que se asigna a la clase de servicio es la cantidad real de memoria de trabajo actual en MB por ranura para cada nodo.

Nota: Si se utilizan todas las ranuras de consulta, Amazon Redshift administra la memoria no asignada. Cuando una cola solicita memoria adicional, el sistema proporciona temporalmente memoria no asignada a la cola.

Para obtener más información acerca de la administración de memoria no asignada, consulta Porcentaje de memoria WLM que se debe usar.

Identificación de los parámetros de ajuste de alto nivel

Usa la tabla SVL_QUERY_METRICS_SUMMARY para comprobar la ejecución detallada y la columna query_queue_time para ver las consultas que están en cola. La columna query_queue_time muestra que la consulta está en la cola para que se ejecute una ranura de WLM.

Tabla de ejemplo:

dev=# select userid, query, service_class, query_cpu_time, query_blocks_read, query_execution_time, query_cpu_usage_percent, query_temp_blocks_to_disk, query_queue_time  from SVL_QUERY_METRICS_SUMMARY where query=29608;

 userid | query | service_class | query_cpu_time | query_blocks_read | query_execution_time | query_cpu_usage_percent | query_temp_blocks_to_disk | query_queue_time
--------+-------+---------------+----------------+-------------------+----------------------+-------------------------+---------------------------+------------------
    100 | 29608 |                    8 |                       18 |                          942 |                                64 |                                   10.05 |                                               |
(1 row)


ev=# select query, step, rows, workmem, label, is_diskbased
from svl_query_summary
where query = 29608
order by workmem desc;

 query | step |   rows   | workmem  |                  label                  | is_diskbased
-------+------+----------+----------+-----------------------------------------+--------------
 29608 |    3 |    49999 | 54263808 | hash   tbl=714                          | f
 29608 |    2 |    49999 |        0 | project                                 | f
 29608 |    0 |    49999 |        0 | scan   tbl=255079 name=part             | f
 29608 |    1 |    49999 |        0 | project                                 | f
 29608 |    6 |  1561938 |        0 | return                                  | f
 29608 |    4 |  1561938 |        0 | project                                 | f
 29608 |    5 |  1561938 |        0 | project                                 | f
 29608 |    2 | 29995220 |        0 | project                                 | f
 29608 |    1 |  1561938 |        0 | return                                  | f
 29608 |    1 | 29995220 |        0 | project                                 | f
 29608 |    0 |  1561938 |        0 | scan   tbl=4893 name=Internal Worktable | f
 29608 |    3 |  1561938 |        0 | hjoin  tbl=714                          | f
 29608 |    0 | 29995220 |        0 | scan   tbl=255087 name=lineorder        | f
(13 rows)

Utiliza la tabla SVL_QUERY_SUMMARY para comprobar la asignación de recursos durante cada paso de la consulta.

Comprueba las columnas is_diskbased y workmem para ver el uso de los recursos. Para obtener más información, consulta Análisis del resumen de la consulta.

Actualización de las propiedades de configuración dinámica de WLM

Utiliza las propiedades de configuración dinámica de WLM para adaptarte a las cargas de trabajo que cambian. Puedes aplicar propiedades dinámicas a la base de datos sin reiniciar el clúster. Sin embargo, el cambio entre el WLM automático y el WLM manual es estático y requiere un reinicio del clúster para que surta efecto.

Para obtener más información, consulta STV_WLM_SERVICE_CLASS_CONFIG.

A continuación, se muestra un ejemplo de un clúster configurado con dos colas:

Queue    Concurrency    % Memory to Use            1        5              60%  
2        5              40%

Si el clúster tiene 200 GB de memoria disponible, la asignación de memoria actual para cada una de las ranuras de cola es similar a la del siguiente ejemplo:

Queue 1: (200 GB * 60% ) / 5 slots  = 24 GB
Queue 2: (200 GB * 40% ) / 5 slots  = 16 GB

Para actualizar las propiedades de configuración del WLM para que sean dinámicas, modifica la configuración. Consulta el siguiente ejemplo de modificación:

Queue    Concurrency    % Memory to Use            1        3              75%  
2        4              25%

Después de modificar la configuración de WLM, la asignación de memoria se actualiza para adaptarse a la carga de trabajo modificada. Ve el siguiente ejemplo:

Queue 1: (200 GB * 75% ) / 3 slots = 50 GB
Queue 2: (200 GB * 25% ) / 4 slots = 12.5 GB

Nota: Si hay consultas en la cola de WLM durante una actualización de configuración dinámica, Amazon Redshift espera a que se completen las consultas. Una vez finalizada la consulta, Amazon Redshift actualiza el clúster con la configuración actualizada.

Utiliza la tabla STV_WLM_SERVICE_CLASS_CONFIG cuando realices la transición a las propiedades de configuración de WLM dinámicas.

Si los valores num_query_tasks y target_num_query_tasks son diferentes, se está produciendo una transición dinámica de WLM. Un valor de -1 indica que está configurado el WLM automático.

Identificación de la memoria insuficiente asignada a la consulta

Si un plan de ejecución de consultas en SVL_QUERY_SUMMARY tiene un valor de is_diskbased establecido en true, asigna más memoria a la consulta. Para asignar más memoria, aumenta la cantidad de ranuras de consulta.

Para obtener más información, consulta wlm_query_slot_count.