Уроки — наблюдения по отладке

Это руководство — часть подборки выводов, собранных на встречах сообщества. Больше практических решений и полезных наблюдений можно найти по конкретным проблемам. Сталкиваетесь с высокими эксплуатационными расходами? Ознакомьтесь с руководством сообщества Оптимизация затрат.

Основные системные таблицы

Эти системные таблицы необходимы для отладки в продакшене:

system.errors

Отображает все активные ошибки в вашем экземпляре ClickHouse.

SELECT name, value, changed 
FROM system.errors 
WHERE value > 0 
ORDER BY value DESC;

system.replicas

Содержит информацию об отставании репликации и состоянии реплик для мониторинга состояния кластера.

SELECT database, table, replica_name, absolute_delay, queue_size, inserts_in_queue
FROM system.replicas 
WHERE absolute_delay > 60
ORDER BY absolute_delay DESC;

system.replication_queue

Содержит подробную информацию для диагностики проблем с репликацией.

SELECT database, table, replica_name, position, type, create_time, last_exception
FROM system.replication_queue 
WHERE last_exception != ''
ORDER BY create_time DESC;

system.merges

Показывает текущие операции слияния и позволяет выявить зависшие процессы.

SELECT database, table, elapsed, progress, is_mutation, total_size_bytes_compressed
FROM system.merges 
ORDER BY elapsed DESC;

system.parts

Критически важна для отслеживания количества частей и выявления проблем с фрагментацией.

SELECT database, table, count() as part_count
FROM system.parts 
WHERE active = 1
GROUP BY database, table
ORDER BY count() DESC;

Распространённые проблемы в продакшене

Проблемы с дисковым пространством

Нехватка дискового пространства в реплицируемых конфигурациях приводит к цепочке проблем. Когда на одном узле заканчивается место, другие узлы продолжают пытаться синхронизироваться с ним, что вызывает всплески сетевого трафика и затрудняет диагностику. Один из участников сообщества потратил 4 часа на отладку проблемы, которая в итоге оказалась обычной нехваткой места на диске. Ознакомьтесь с этим запросом, чтобы отслеживать состояние дискового хранилища в конкретном кластере.

Если вы используете AWS, имейте в виду, что стандартные EBS-тома общего назначения по умолчанию ограничены 16 ТБ.

Ошибка «Too many частей»

Частые небольшие вставки приводят к проблемам с производительностью. В сообществе установили, что при скорости вставки выше 10 в секунду часто возникает ошибка «too many частей», потому что ClickHouse не успевает объединять части.

Решения:

Группируйте данные в батчи с порогами 30 секунд или 200 МБ
Включите async_insert для автоматического батчинга
Используйте буферные таблицы для батчинга на стороне сервера
Настройте Kafka для контролируемого размера батчей

Официальная рекомендация: минимум 1 000 строк на одну вставку, в идеале — от 10 000 до 100 000.

Проблемы с некорректными временными метками

Приложения, отправляющие данные с произвольными временными метками, создают проблемы с партициями. В результате появляются партиции с данными за нереалистичные даты (например, 1998 или 2050 год), что приводит к непредсказуемому поведению хранилища.

Риски операций `ALTER`

Крупные операции ALTER на таблицах объёмом в несколько терабайт могут потреблять значительные ресурсы и даже блокировать базы данных. В одном из примеров из сообщества изменение типа Integer на Float для 14 ТБ данных привело к блокировке всей базы данных и потребовало её восстановления из резервных копий.

Отслеживайте ресурсоёмкие мутации:

SELECT database, table, mutation_id, command, parts_to_do, is_done
FROM system.mutations 
WHERE is_done = 0;

Сначала проверяйте изменения схемы на небольших наборах данных.

Память и производительность

Внешняя агрегация

Включите внешнюю агрегацию для операций, интенсивно использующих память. Она работает медленнее, но помогает избежать сбоев из-за нехватки памяти, выгружая промежуточные данные на диск. Для этого можно использовать max_bytes_before_external_group_by — этот параметр помогает предотвратить сбои из-за нехватки памяти при больших операциях GROUP BY. Подробнее об этой настройке читайте здесь.

SELECT 
    column1,
    column2,
    COUNT(*) as count,
    SUM(value) as total
FROM large_table
GROUP BY column1, column2
SETTINGS max_bytes_before_external_group_by = 1000000000; -- 1GB threshold

Подробности об async insert

Async insert автоматически объединяет небольшие вставки в батчи на стороне сервера, чтобы повысить производительность. Вы можете настроить, ждать ли записи данных на диск перед отправкой подтверждения: немедленный ответ быстрее, но менее надежен с точки зрения сохранности данных. В современных версиях поддерживается дедупликация для обработки дублирующихся данных внутри батчей.

Связанная документация

Выбор стратегии вставки

Настройка distributed таблицы

По умолчанию distributed таблицы используют однопоточную вставку. Включите insert_distributed_sync, чтобы задействовать параллельную обработку и немедленную отправку данных в сегменты.

Следите за накоплением временных данных при использовании distributed таблиц.

Пороговые значения для мониторинга производительности

Рекомендуемые сообществом пороговые значения для мониторинга:

Число частей на партицию: желательно менее 100
Задержанные вставки: должно оставаться равным нулю
Частота вставок: для оптимальной производительности — примерно не более 1 в секунду