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

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

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

system.errors

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

system.replicas

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

system.replication_queue

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

system.merges

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

system.parts

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

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

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

Нехватка дискового пространства в реплицируемых конфигурациях приводит к цепочке проблем. Когда на одном узле заканчивается место, другие узлы продолжают пытаться синхронизироваться с ним, что вызывает всплески сетевого трафика и затрудняет диагностику. Один из участников сообщества потратил 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 ТБ данных привело к блокировке всей базы данных и потребовало её восстановления из резервных копий. Отслеживайте ресурсоёмкие мутации:
Сначала проверяйте изменения схемы на небольших наборах данных.

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

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

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

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

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

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

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

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

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

Краткая справка

Видео

Последнее изменение 10 июня 2026 г.