# Настройки MergeTree таблиц {#merge-tree-settings} Значения по умолчанию (для всех таблиц) задаются в config.xml в секции merge_tree. Пример: ```text 5 ``` Эти значения можно задать (перекрыть) у таблиц в секции `SETTINGS` у команды `CREATE TABLE`. Пример: ```sql CREATE TABLE foo ( `A` Int64 ) ENGINE = MergeTree ORDER BY tuple() SETTINGS max_suspicious_broken_parts = 500; ``` Или изменить с помощью команды `ALTER TABLE ... MODIFY SETTING`. Пример: ```sql ALTER TABLE foo MODIFY SETTING max_suspicious_broken_parts = 100; ``` ## parts_to_throw_insert {#parts-to-throw-insert} Eсли число кусков в партиции превышает значение `parts_to_throw_insert` INSERT прерывается с исключением `Too many parts (N). Merges are processing significantly slower than inserts`. Возможные значения: - Положительное целое число. Значение по умолчанию: 300. Для достижения максимальной производительности запросов `SELECT` необходимо минимизировать количество обрабатываемых кусков, см. [Дизайн MergeTree](../../development/architecture.md#merge-tree). Можно установить большее значение 600 (1200), это уменьшит вероятность возникновения ошибки `Too many parts`, но в тоже время вы позже обнаружите возможную проблему со слияниями (например из-за недостатка места на диске), и деградацию производительности `SELECT`. ## parts_to_delay_insert {#parts-to-delay-insert} Eсли число кусков в партиции превышает значение `parts_to_delay_insert` `INSERT` искусственно замедляется. Возможные значения: - Положительное целое число. Значение по умолчанию: 150. ClickHouse искусственно выполняет `INSERT` дольше (добавляет 'sleep'), чтобы фоновый механизм слияния успевал слиять куски быстрее чем они добавляются. ## max_delay_to_insert {#max-delay-to-insert} Величина в секундах, которая используется для расчета задержки `INSERT`, если число кусков в партиции превышает значение [parts_to_delay_insert](#parts-to-delay-insert). Возможные значения: - Положительное целое число. Значение по умолчанию: 1. Величина задержи (в миллисекундах) для `INSERT` вычисляется по формуле: ```code max_k = parts_to_throw_insert - parts_to_delay_insert k = 1 + parts_count_in_partition - parts_to_delay_insert delay_milliseconds = pow(max_delay_to_insert * 1000, k / max_k) ``` Т.е. если в партиции уже 299 кусков и parts_to_throw_insert = 300, parts_to_delay_insert = 150, max_delay_to_insert = 1, `INSERT` замедлится на `pow( 1 * 1000, (1 + 299 - 150) / (300 - 150) ) = 1000` миллисекунд. ## old_parts_lifetime {#old_parts_lifetime} Время (в секундах) хранения неактивных кусков, для защиты от потери данных при спонтанной перезагрузке сервера или О.С. Возможные значения: - Положительное целое число. Значение по умолчанию: 480. После слияния нескольких кусков в новый кусок, ClickHouse помечает исходные куски как неактивные и удаляет их после `old_parts_lifetime` секунд. Неактивные куски удаляются если они не используются в текущих запросах, т.е. если счетчик ссылок куска -- `refcount` равен нулю. Неактивные куски удаляются не сразу, потому что при записи нового куска не вызывается `fsync`, т.е. некоторое время новый кусок находится только в оперативной памяти сервера (кеше О.С.). Т.о. при спонтанной перезагрузке сервера, новый (смерженный) кусок может быть потерян или испорчен. В этом случае ClickHouse при загрузке при проверке целостности кусков обнаружит это и вернет неактивные куски в список активных и позже заново их смержит. Сломанный кусок в этом случае переименовывается (добавляется префикс broken_) и перемещается в папку detached. Стандартное значение Linux dirty_expire_centisecs - 30 секунд (максимальное время, которое записанные данные хранятся только в оперативной памяти), но при больших нагрузках на дисковую систему, данные могут быть записаны намного позже (30 сек.), экспериментально было найдено время - 480 секунд, за которое почти гарантировано новый кусок будет записан на диск и безопасно удалять неактивные куски. [Оригинальная статья](https://clickhouse.tech/docs/ru/operations/settings/merge_tree_settings/)