Сайзинг стенда: пересмотреть выделенные контейнерам ресурсы #21

New Issue

2026-07-31T18:28:02+03:00

ddmitry commented

2026-07-31 18:28:02 +03:00

Стенд упирается в память ноды ClickHouse на обычной работе: пробник валится на
CREATE TABLE ON CLUSTER, и вместе с ним краснеют make smoke и
make smoke-guards. Тикет — чтобы записать числа и решить отдельно, что делать
с выделением ресурсов контейнерам.

Что случилось

31 июля 2026 года, стенд поднят несколько часов, за сессию около двадцати
прогонов пробника (обычный make smoke делает один). Задача prepare_tables
пробника test_clickhouse упала:

Code: 241. DB::Exception: (total) memory limit exceeded: would use 923.08 MiB
(attempt to allocate chunk of 0.00 B), current RSS: 774.16 MiB,
maximum: 921.60 MiB. (MEMORY_LIMIT_EXCEEDED) (for url http://clickhouse-01:8123)

make smoke дал 24 из 25, make smoke-guards упал на последнем шаге
(«после восстановления стенд не проходит make smoke»). Перезапуск
clickhouse-01 вернул RSS к 531 МиБ, и всё позеленело. То есть это не разовый
сбой, а дрейф потребления: нода набирает память по мере работы и однажды
роняет очередной запрос.

Почему так выходит

настройка	значение
`mem_limit` контейнера ноды	1 ГиБ
`max_server_memory_usage` (0,9 от контейнера)	921,6 МиБ
`mark_cache_size`	5 ГиБ (заводское)
`index_mark_cache_size`	5 ГиБ (заводское)
`uncompressed_cache_size`	8 ГиБ (заводское)

ClickHouse не знает, что живёт в коробке на гигабайт: кэши остались заводскими,
суммарно на тринадцать гигабайт. Сразу он их не выделяет, но набивает по мере
работы, упирается в потолок сервера и отказывает не кэшу, а очередному запросу.
В infra/clickhouse/config.d/ размеры кэшей сейчас не заданы.

Что стоит рассмотреть

Прижать кэши по размеру коробки: mark_cache_size, index_mark_cache_size,
uncompressed_cache_size. Лечит причину и уронит базовое потребление.
Пересмотреть выделенные ресурсы контейнеров целиком, а не одной ноде.
Сейчас: clickhouse-01 и clickhouse-02 по 1 ГиБ, kafka 1 ГиБ,
superset 1 ГиБ, airflow-scheduler 640 МиБ, airflow-apiserver 512 МиБ,
airflow-dag-processor 384 МиБ, clickhouse-keeper 512 МиБ,
prometheus 512 МиБ, grafana 512 МиБ, postgres-metadata 256 МиБ.
Учесть, что любое повышение упирается в собственный предел стенда:
make smoke требует не больше 3242,5 МиБ на весь стенд, а занимает он
3181 МиБ — запас 61 МиБ. Поднимать потолки, не прижав кэши, значит проедать
бюджет и переносить порог, то есть ломать учебную проверку «стенд помещается
в отведённое».

Что именно менять — решается по этому тикету отдельно; заранее решение не
принято.

Сначала прочитать

compose.yaml — mem_limit всех сервисов.
infra/clickhouse/config.d/ — что уже настроено у нод.
scripts/stand-smoke.sh, проверка объёма стенда — порог 3242,5 МиБ.
docs/specs/2026-07-30-stand-v2-realism.md — откуда взялся предел 3,4 ГБ.

Проверка

make smoke
make smoke-cluster

Стенд упирается в память ноды ClickHouse на обычной работе: пробник валится на `CREATE TABLE ON CLUSTER`, и вместе с ним краснеют `make smoke` и `make smoke-guards`. Тикет — чтобы записать числа и решить отдельно, что делать с выделением ресурсов контейнерам. ## Что случилось 31 июля 2026 года, стенд поднят несколько часов, за сессию около двадцати прогонов пробника (обычный `make smoke` делает один). Задача `prepare_tables` пробника `test_clickhouse` упала: ``` Code: 241. DB::Exception: (total) memory limit exceeded: would use 923.08 MiB (attempt to allocate chunk of 0.00 B), current RSS: 774.16 MiB, maximum: 921.60 MiB. (MEMORY_LIMIT_EXCEEDED) (for url http://clickhouse-01:8123) ``` `make smoke` дал 24 из 25, `make smoke-guards` упал на последнем шаге («после восстановления стенд не проходит make smoke»). Перезапуск `clickhouse-01` вернул RSS к 531 МиБ, и всё позеленело. То есть это не разовый сбой, а дрейф потребления: нода набирает память по мере работы и однажды роняет очередной запрос. ## Почему так выходит | настройка | значение | | --- | --- | | `mem_limit` контейнера ноды | 1 ГиБ | | `max_server_memory_usage` (0,9 от контейнера) | 921,6 МиБ | | `mark_cache_size` | 5 ГиБ (заводское) | | `index_mark_cache_size` | 5 ГиБ (заводское) | | `uncompressed_cache_size` | 8 ГиБ (заводское) | ClickHouse не знает, что живёт в коробке на гигабайт: кэши остались заводскими, суммарно на тринадцать гигабайт. Сразу он их не выделяет, но набивает по мере работы, упирается в потолок сервера и отказывает не кэшу, а очередному запросу. В `infra/clickhouse/config.d/` размеры кэшей сейчас не заданы. ## Что стоит рассмотреть - Прижать кэши по размеру коробки: `mark_cache_size`, `index_mark_cache_size`, `uncompressed_cache_size`. Лечит причину и уронит базовое потребление. - Пересмотреть выделенные ресурсы контейнеров целиком, а не одной ноде. Сейчас: `clickhouse-01` и `clickhouse-02` по 1 ГиБ, `kafka` 1 ГиБ, `superset` 1 ГиБ, `airflow-scheduler` 640 МиБ, `airflow-apiserver` 512 МиБ, `airflow-dag-processor` 384 МиБ, `clickhouse-keeper` 512 МиБ, `prometheus` 512 МиБ, `grafana` 512 МиБ, `postgres-metadata` 256 МиБ. - Учесть, что любое повышение упирается в собственный предел стенда: `make smoke` требует не больше 3242,5 МиБ на весь стенд, а занимает он 3181 МиБ — запас 61 МиБ. Поднимать потолки, не прижав кэши, значит проедать бюджет и переносить порог, то есть ломать учебную проверку «стенд помещается в отведённое». Что именно менять — решается по этому тикету отдельно; заранее решение не принято. ## Сначала прочитать 1. `compose.yaml` — `mem_limit` всех сервисов. 2. `infra/clickhouse/config.d/` — что уже настроено у нод. 3. `scripts/stand-smoke.sh`, проверка объёма стенда — порог 3242,5 МиБ. 4. `docs/specs/2026-07-30-stand-v2-realism.md` — откуда взялся предел 3,4 ГБ. ## Проверка ``` make smoke make smoke-cluster ```

ddmitry added the needs-triage label 2026-07-31 18:28:23 +03:00

ddmitry commented

2026-07-31 19:15:28 +03:00

Замеры 31 июля 2026 года, после дня прогонов проверок.

Проверка памяти в make smoke стала красной: стенд занял 3261,0 MiB при пороге 3242,5 MiB. Обе ноды ClickHouse держали при этом 765,6 и 834,8 MiB из своего гигабайта — вдвоём почти половину стенда, тогда как остальные одиннадцать контейнеров вместе дали 1660 MiB и все были далеко от своих пределов.

Перезапуск обеих нод сбросил их до 558,8 и 520,9 MiB. Но следующий же прогон make smoke снова дал красное — 3250,0 MiB: один запуск пробника возвращает кэшам часть съеденного.

Отсюда два вывода к решению о ресурсах:

запас между обычным состоянием стенда и порогом 3,4 ГБ — единицы мегабайт, то есть его фактически нет;
растёт не рабочая память, а кэши ClickHouse: контейнеру отведён 1 ГБ, а mark_cache_size, index_mark_cache_size и uncompressed_cache_size остались заводскими (5, 5 и 8 ГБ).

Пока тикет не решён, зелёный make smoke зависит от того, сколько прогонов прошло с последнего перезапуска ClickHouse.

Замеры 31 июля 2026 года, после дня прогонов проверок. Проверка памяти в make smoke стала красной: стенд занял 3261,0 MiB при пороге 3242,5 MiB. Обе ноды ClickHouse держали при этом 765,6 и 834,8 MiB из своего гигабайта — вдвоём почти половину стенда, тогда как остальные одиннадцать контейнеров вместе дали 1660 MiB и все были далеко от своих пределов. Перезапуск обеих нод сбросил их до 558,8 и 520,9 MiB. Но следующий же прогон make smoke снова дал красное — 3250,0 MiB: один запуск пробника возвращает кэшам часть съеденного. Отсюда два вывода к решению о ресурсах: - запас между обычным состоянием стенда и порогом 3,4 ГБ — единицы мегабайт, то есть его фактически нет; - растёт не рабочая память, а кэши ClickHouse: контейнеру отведён 1 ГБ, а mark_cache_size, index_mark_cache_size и uncompressed_cache_size остались заводскими (5, 5 и 8 ГБ). Пока тикет не решён, зелёный make smoke зависит от того, сколько прогонов прошло с последнего перезапуска ClickHouse.

ddmitry referenced this issue

2026-07-31 19:21:01 +03:00

Форма пробника Kafka: переписать по образцу test_clickhouse #22

ddmitry referenced this issue from a commit

2026-07-31 19:21:48 +03:00

docs(airflow): шапка теста ClickHouse объясняет, что он проверяет

ddmitry referenced this issue

2026-07-31 19:22:22 +03:00

refactor(airflow): пробник ClickHouse разбит на четыре задачи #23

ddmitry referenced this issue from a commit

2026-07-31 20:20:34 +03:00

refactor(airflow): пробник Kafka разрезан на запись и чтение