> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-postgresql-tls-support.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Уроки — наблюдения по отладке
> Найдите решения самых распространённых проблем ClickHouse, включая медленные запросы, ошибки памяти, проблемы с подключением и конфигурацией.
*Это руководство — часть подборки выводов, собранных на встречах сообщества. Больше практических решений и полезных наблюдений можно [найти по конкретным проблемам](/ru/resources/support-center/tips-and-tricks/community-wisdom).*
*Сталкиваетесь с высокими эксплуатационными расходами? Ознакомьтесь с руководством сообщества [Оптимизация затрат](/ru/resources/support-center/tips-and-tricks/cost-optimization).*
## Основные системные таблицы
Эти системные таблицы необходимы для отладки в продакшене:
### system.errors
Отображает все активные ошибки в вашем экземпляре ClickHouse.
```sql theme={null}
SELECT name, value, changed
FROM system.errors
WHERE value > 0
ORDER BY value DESC;
```
### system.replicas
Содержит информацию об отставании репликации и состоянии реплик для мониторинга состояния кластера.
```sql theme={null}
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
Содержит подробную информацию для диагностики проблем с репликацией.
```sql theme={null}
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
Показывает текущие операции слияния и позволяет выявить зависшие процессы.
```sql theme={null}
SELECT database, table, elapsed, progress, is_mutation, total_size_bytes_compressed
FROM system.merges
ORDER BY elapsed DESC;
```
### system.parts
Критически важна для отслеживания количества частей и выявления проблем с фрагментацией.
```sql theme={null}
SELECT database, table, count() as part_count
FROM system.parts
WHERE active = 1
GROUP BY database, table
ORDER BY count() DESC;
```
## Распространённые проблемы в продакшене
### Проблемы с дисковым пространством
Нехватка дискового пространства в реплицируемых конфигурациях приводит к цепочке проблем. Когда на одном узле заканчивается место, другие узлы продолжают пытаться синхронизироваться с ним, что вызывает всплески сетевого трафика и затрудняет диагностику. Один из участников сообщества потратил 4 часа на отладку проблемы, которая в итоге оказалась обычной нехваткой места на диске. Ознакомьтесь с этим [запросом](/ru/resources/support-center/knowledge-base/queries-sql/useful-queries-for-troubleshooting#show-disk-storage-number-of-parts-number-of-rows-in-systemparts-and-marks-across-databases), чтобы отслеживать состояние дискового хранилища в конкретном кластере.
Если вы используете AWS, имейте в виду, что стандартные EBS-тома общего назначения по умолчанию ограничены 16 ТБ.
### Ошибка «Too many частей»
Частые небольшие вставки приводят к проблемам с производительностью. В сообществе установили, что при скорости вставки выше 10 в секунду часто возникает ошибка «too many частей», потому что ClickHouse не успевает объединять части.
**Решения:**
* Группируйте данные в батчи с порогами 30 секунд или 200 МБ
* Включите async\_insert для автоматического батчинга
* Используйте буферные таблицы для батчинга на стороне сервера
* Настройте Kafka для контролируемого размера батчей
[Официальная рекомендация](/ru/concepts/best-practices/selecting-an-insert-strategy#batch-inserts-if-synchronous): минимум 1 000 строк на одну вставку, в идеале — от 10 000 до 100 000.
### Проблемы с некорректными временными метками
Приложения, отправляющие данные с произвольными временными метками, создают проблемы с партициями. В результате появляются партиции с данными за нереалистичные даты (например, 1998 или 2050 год), что приводит к непредсказуемому поведению хранилища.
### Риски операций `ALTER`
Крупные операции `ALTER` на таблицах объёмом в несколько терабайт могут потреблять значительные ресурсы и даже блокировать базы данных. В одном из примеров из сообщества изменение типа Integer на Float для 14 ТБ данных привело к блокировке всей базы данных и потребовало её восстановления из резервных копий.
**Отслеживайте ресурсоёмкие мутации:**
```sql theme={null}
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`. Подробнее об этой настройке читайте [здесь](/ru/reference/settings/session-settings#max_bytes_before_external_group_by).
```sql theme={null}
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; -- порог 1 ГБ
```
### Подробности об async insert
Async insert автоматически объединяет небольшие вставки в батчи на стороне сервера, чтобы повысить производительность. Вы можете настроить, ждать ли записи данных на диск перед отправкой подтверждения: немедленный ответ быстрее, но менее надежен с точки зрения сохранности данных. В современных версиях поддерживается дедупликация для обработки дублирующихся данных внутри батчей.
**Связанная документация**
* [Выбор стратегии вставки](/ru/concepts/best-practices/selecting-an-insert-strategy#asynchronous-inserts)
### Настройка distributed таблицы
По умолчанию distributed таблицы используют однопоточную вставку. Включите `insert_distributed_sync`, чтобы задействовать параллельную обработку и немедленную отправку данных в сегменты.
Следите за накоплением временных данных при использовании distributed таблиц.
### Пороговые значения для мониторинга производительности
Рекомендуемые сообществом пороговые значения для мониторинга:
* Число частей на партицию: желательно менее 100
* Задержанные вставки: должно оставаться равным нулю
* Частота вставок: для оптимальной производительности — примерно не более 1 в секунду
**Связанная документация**
* [Пользовательский ключ партиционирования](/ru/reference/engines/table-engines/mergetree-family/custom-partitioning-key)
## Краткая справка
| Проблема | Обнаружение | Решение |
| -------------------- | ------------------------------------------------ | ----------------------------------------------------- |
| Место на диске | Проверьте общий объём данных в `system.parts` | Следите за использованием, планируйте масштабирование |
| Слишком много частей | Подсчитайте количество частей для каждой таблицы | Объединяйте вставки в батчи, включите async\_insert |
| Задержка репликации | Проверьте задержку в `system.replicas` | Следите за сетью, перезапускайте реплики |
| Некорректные данные | Проверяйте даты партиций | Добавьте проверку временных меток |
| Зависшие мутации | Проверьте статус в `system.mutations` | Сначала тестируйте на небольшом объёме данных |
### Видео
* [10 уроков по эксплуатации ClickHouse](https://www.youtube.com/watch?v=liTgGiTuhJE)
* [Быстрые, параллельные и согласованные асинхронные вставки в ClickHouse](https://www.youtube.com/watch?v=AsMPEfN5QtM)