CPU 80%. Как найти проблемный запрос в ClickHouse?

[akardapolov]

1. system.processes → что висит прямо сейчас

В Dimension-UI в шаблонах можно выбрать визуальный мониторинг процессов для ClickHouse (а-ля история активных сессий в СУБД Oracle).

Templates

[shahvaly]

Спасибо за ссылку! Для общего мониторинга у нас используется Grafana, но Dimension-UI выглядит интересно для диагностики. Буду тестировать)

[seriych]

query NOT ILIKE '%system.query_log%'

Если анализировать за большой промежуток времени, то лучше не "лайкать" query_log, так как это может быть долго, а вместо этого использовать not has(tables, 'system.query_log').

Когда к ClickHouse обращаются несколько сервисов (дашборды, оркестраторы пайплайнов, ручные запросы аналитиков), в query_log тысячи записей, и непонятно, кто создаёт нагрузку.

Странно, что тут не написано про банальные initial_user и user. Ну и есть еще полезные client_hostname и initial_address. Статья про поиск проблемы, а наличие прописанного log_comment - это не дефолтное поведение. Про это, наверное, можно было бы в конце статьи написать как рекомендацию к использованию.

Пример тяжёлого запроса
…
FROM events final
WHERE event_date > ‘2024-01-01’
…
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_id, user_id, event_date);
…
Теперь картина ясна. Что можно сделать?

Самое эффективное здесь будет добавить в конец запроса settings do_not_merge_across_partitions_select_final = 1;.
А еще помимо замены на uniq можно воспользоваться хаком из моей статьи :-) uniqExact(cityHash64(event_id)) - всего x2 памяти сэкономим, но посчитаем точно.

Ну и не по теме статьи, но если это реальная таблица у вас, то скорее всего у вас там ключ сортировки неоптимальный. На первом месте event_id UUID и после него всё остальное уже не имеет смысла в плане эффективности ключа. Полагаю любой из вариантов (event_date, user_id, event_id) или (user_id, event_date, event_id) будет лучше, а если вам нужен поиск по event_id, то можно bloom_filter на эту колонку навесить.

[shahvaly]

Спасибо большое за комментарий! По делу и содержательно

Уже поправил статью по вашим замечаниям: добавил user, initial_user, а вместо ILIKE использовал NOT has(tables, 'system.query_log').

Когда писал текст, слишком сфокусировался в сценарии работы с оркестратором, поэтому часть общих моментов действительно упустил - обновил блок с метками.

Пример с таблицей в статье синтетический и специально сделан неидеальным, чтобы было удобнее разбирать проблемные места. Но это правда лучше было сказать прямо, это тоже уточнил

Отдельное спасибо за uniqExact(cityHash64(event_id)) - интересный прием, уже пошел читать вашу статью 😄