Настройка Resource Group на основе Audit Log¶

В StarRocks Resource Groups обеспечивают эффективную изоляцию ресурсов путём выделения лимитов CPU, памяти и параллелизма на основе классификаторов, таких как идентичность пользователя и тип запроса. Эта функция критична для эффективного использования ресурсов в multi‑tenant среде.

Традиционная настройка resource group часто опирается на эмпирические оценки. Анализируя исторические данные запросов из таблицы audit log starrocks_audit_db__.starrocks_audit_tbl__, администраторы могут применять data‑driven подход к тюнингу resource groups. Ключевые метрики — CPU time, потребление памяти и параллелизма — дают объективное представление о характеристиках нагрузки.

Такой подход помогает:

• Предотвращать рост латентности запросов из‑за конкуренции за ресурсы

• Защищать кластер от истощения ресурсов

• Повышать общую стабильность и предсказуемость

В этом разделе — пошаговое руководство по выводу корректных параметров resource group на основе паттернов нагрузки, наблюдаемых в audit logs.

Распределение CPU¶

Цель¶

Определить потребление CPU на пользователя и пропорционально выделить CPU с помощью cpu_weight или exclusive_cpu_cores.

Анализ¶

Следующий SQL агрегирует суммарное CPU‑время по пользователю (cpuCostNs) за последние 30 дней, переводит его в секунды и вычисляет долю от общего CPU‑времени.

SELECT 
    user,
    SUM(cpuCostNs) / 1e9 AS total_cpu_seconds,                  -- Query the total CPU time.
    (
        SUM(cpuCostNs) /
        (
            SELECT SUM(cpuCostNs)
            FROM starrocks_audit_db__.starrocks_audit_tbl__
            WHERE state IN ('EOF','OK')
              AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
        )
    ) * 100 AS cpu_usage_percentage                             -- Calculate the percentage of total CPU usage per user.
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')                                     -- Include queries that are finished only.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)    -- Query the data of the last 30 days.
GROUP BY user
ORDER BY total_cpu_seconds DESC
LIMIT 20;                                                       -- List the top 20 users with the most CPU resource consumption.

Рекомендации¶

Предположим фиксированное число CPU‑ядер на BE (например, 64). Если на пользователя приходится 16% (cpu_usage_percentage) общего CPU‑времени, разумно выделить примерно 64 × 16% ≈ 11 cores.

Можно настроить CPU‑лимиты для resource group так:

• exclusive_cpu_cores:

  • Значение не должно превышать общее число ядер на одном BE.

  • Сумма exclusive_cpu_cores всех групп не должна превышать число ядер одного BE.

• cpu_weight:

  • Применяется только к группам с мягкой изоляцией.

  • Определяет относительную долю CPU между конкурирующими запросами на оставшихся ядрах.

  • Не сопоставляется напрямую фиксированному числу CPU‑ядер.

Управление памятью¶

Цель¶

Выявить пользователей, интенсивно потребляющих память, и определить уместные лимиты и предохранители.

Анализ¶

Следующий SQL вычисляет максимальное потребление памяти на пользователя (memCostBytes) для одного запроса за последние 30 дней.

SELECT 
    user,
    MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb            -- Max memory usage (in MB) per query.
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')                                    -- Include queries that are finished only.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)   -- Query the data of the last 30 days.
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20;                                                      -- List the top 20 users with the most memory resource consumption.

Рекомендации¶

max_mem_mb отражает совокупную память по всем BE. Оценочное потребление на один BE: max_mem_mb / number_of_BEs.

Настройка лимитов памяти для resource group:

• big_query_mem_limit:

  • Защищает кластер от аномально «крупных» запросов.

  • Устанавливайте достаточно высокий порог, чтобы избежать ложных остановок.

• mem_limit:

  • В большинстве случаев установите высокое значение (например, 0.9).

Контроль параллелизма¶

Цель¶

Определить пиковый параллелизм запросов на пользователя и задать уместные значения concurrency_limit.

Анализ¶

Следующий SQL анализирует поминутный параллелизм запросов за последние 30 дней и извлекает максимальное значение для каждого пользователя.

WITH UserConcurrency AS (
    SELECT 
        user,
        DATE_FORMAT(timestamp, '%Y-%m-%d %H:%i') AS minute_bucket,
        COUNT(*) AS query_concurrency
    FROM starrocks_audit_db__.starrocks_audit_tbl__
    WHERE state IN ('EOF', 'OK')                              -- Include queries that are finished only.
      AND timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY)       -- Query the data of the last 30 days.
      AND LOWER(stmt) LIKE '%select%'                         -- Include SELECT statements only.
    GROUP BY user, minute_bucket
    HAVING query_concurrency > 1                              -- Exclude scenarios where concurrency is less than one query per minute.
)
SELECT 
    user,
    minute_bucket,
    query_concurrency / 60.0 AS query_concurrency_per_second  -- Query the per-second concurrency.
FROM (
    SELECT 
        user,
        minute_bucket,
        query_concurrency,
        ROW_NUMBER() OVER (
            PARTITION BY user
            ORDER BY query_concurrency DESC
        ) AS rn
    FROM UserConcurrency
) ranked
WHERE rn = 1                                                  -- Keep the highest record for each user.
ORDER BY query_concurrency_per_second DESC
LIMIT 50;                                                     -- List the top 50 users with the highest concurrency.

Рекомендации¶

Анализ проводится с минутной гранулярностью; фактический посекундный параллелизм может быть выше.

Настройка ограничений параллелизма:

• concurrency_limit

  • Задайте примерно 1.5× от наблюдавшегося пика, чтобы оставить запас.

  • Для пользователей с экстремальными всплесками параллелизма можно включить Query Queues для сглаживания пиков и защиты стабильности кластера.

Изоляция ресурсов для асинхронных Materialized View¶

Цель¶

Исключить влияние операций обновления асинхронных materialized view на интерактивные запросы.

Анализ¶

Следующий SQL выявляет «ресурсоёмкие» операции обновления MV, обычно выраженные INSERT OVERWRITE.

SELECT 
    user,
    MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb             -- Max memory usage (in MB) per query.
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')                                     -- Include queries that are finished only.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)    -- Query the data of the last 30 days.
  AND LOWER(stmt) LIKE '%insert overwrite%'                     -- Include materialized view refresh operations only.
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20;                                                       -- List the top 20 users with the most memory resource consumption.

Рекомендации¶

StarRocks по умолчанию предоставляет системную resource group (default_mv_wg) для задач обновления materialized view. Тем не менее настоятельно рекомендуется создать выделенную resource group для таких задач, чтобы обеспечить жёсткую изоляцию и не допустить деградации производительности foreground‑запросов.

Инструкции по настройке лимитов resource group см. в разделах Best Practice for CPU Resource Allocation и Best Practice for Memory Management.

Ниже — лишь пример создания и назначения выделенной resource group для задач обновления materialized view.

1. Создайте выделенную resource group для обновления MV:

   CREATE RESOURCE GROUP rg_mv
   TO (
       user = 'mv_user',
       query_type IN ('insert', 'select')
   )
   WITH (
       'cpu_weight' = '32',
       'mem_limit' = '0.9',
       'concurrency_limit' = '10',
       'spill_mem_limit_threshold' = '0.5'
   );
   

2. Привяжите resource group к materialized view.

   • При создании materialized view:

   CREATE MATERIALIZED VIEW mv_example
   REFRESH ASYNC
   PROPERTIES (
       'resource_group' = 'rg_mv'
   )
   AS
   SELECT * FROM example_table;
   

   • Для существующего materialized view:

   ALTER MATERIALIZED VIEW mv_example SET ("resource_group" = "rg_mv");