Ресурсный бюджет стенда на 16 ГБ #12

New Issue

2026-07-26T21:39:13+03:00

ddmitry commented

2026-07-26 21:39:13 +03:00

Part of #10

Тело не переносилось: issue закрыт задолго до переноса, оригинал остался на GitHub (аккаунт заблокирован 2026-07-26). Название сохранено ради сквозной нумерации и ссылок #NN.

Гист резолюции (из карты): полный стенд в покое ≈3,4 ГБ; 2×1 добавляет ≈0,6–0,8 ГБ (влезает свободно), 2×2 — ≈1,7–1,9 ГБ (влезает, но впритык к дефолтному бюджету WSL2 ~8 ГБ); координатором брать clickhouse-keeper, не ZooKeeper.

Part of #10 Тело не переносилось: issue закрыт задолго до переноса, оригинал остался на GitHub (аккаунт заблокирован 2026-07-26). Название сохранено ради сквозной нумерации и ссылок #NN. Гист резолюции (из карты): полный стенд в покое ≈3,4 ГБ; 2×1 добавляет ≈0,6–0,8 ГБ (влезает свободно), 2×2 — ≈1,7–1,9 ГБ (влезает, но впритык к дефолтному бюджету WSL2 ~8 ГБ); координатором брать clickhouse-keeper, не ZooKeeper.

ddmitry added the wayfinder:research label 2026-07-26 21:39:13 +03:00

ddmitry closed this issue

2026-07-26 21:39:14 +03:00

ddmitry referenced this issue

2026-07-26 21:39:16 +03:00

Кластер: где живёт опыт менти и какая топология #14

ddmitry referenced this issue

2026-07-26 21:55:13 +03:00

Модель данных: широкое событие и второй источник #18

ddmitry commented

2026-07-26 21:55:15 +03:00

Резолюция (дословный перенос с GitHub, автор dementev-dev):

Ресурсный бюджет стенда на 16 ГБ (issue #12)

Кратко: замерил память полного стенда (11 контейнеров), прикинул добавку второго узла ClickHouse и координатора (Keeper/ZooKeeper), сравнил с бюджетом WSL2 на ноутбуке 16 ГБ.

Как мерил

Поднял полный стенд: make up (10 сервисов) + Superset (уже был поднят) = 11 контейнеров.
Дал 2–3 минуты устояться, снял docker stats --no-stream дважды с разницей в минуту — цифры не менялись, стенд стабилен в состоянии покоя (без активного ETL и без генератора живого трафика).
Прогнал docker system df для диска.

Важная оговорка: это память в состоянии покоя (idle). Во время реальных запросов, ETL-прогона в Airflow или отрисовки дашборда в Superset потребление памяти может быть заметно выше. Ниже — оценка "снизу", не пиковая нагрузка.

Память по контейнерам (стенд в покое)

Контейнер	Память	Роль
kafka	937 МБ	брокер сообщений
airflow-webserver	764 МБ	веб-интерфейс Airflow
airflow-scheduler	416 МБ	планировщик DAG'ов
clickhouse	511 МБ	основное хранилище (DWH)
kafka-ui	341 МБ	веб-интерфейс для Kafka
superset	197 МБ	BI-дашборды
postgres-metadata	100 МБ	метабаза Airflow/Superset
grafana	91 МБ	мониторинг-дашборды
statsd-exporter	13 МБ	мост метрик Airflow → Prometheus
prometheus	40 МБ	сбор метрик
kafka-exporter	8 МБ	метрики Kafka для Prometheus
Итого (11 контейнеров)	≈ 3,4 ГБ

Генератор живого трафика (generator, профиль live-generator) в замер не попал — он не поднимается командой make up. Если менти параллельно гоняет генератор, добавится ещё немного памяти сверху (отдельно не мерил).

CPU у всех контейнеров в покое был низким (в основном до 1–4%) — по процессору стенд не узкое место, узкое место — память.

Диск (докладом, не основной вопрос)

docker system df на этой машине показывает много образов от посторонних проектов — они не в счёт. Только для стенда:

образы (свои, без пересечений с чужими) — примерно 2,5–2,7 ГБ;
volumes: clickhouse-data ≈ 194 МБ, kafka-data ≈ 1,6 ГБ (объём зависит от того, сколько данных прогнали через Kafka — сейчас раздутый после предыдущих сессий), pgmeta ≈ 79 МБ, grafana_lib ≈ 25 МБ.

Диск на ноутбуке 16 ГБ обычно не проблема (сотни гигабайт свободно), поэтому дальше в отчёте — только память.

Добавка: второй узел ClickHouse + координатор

Взял память замеренного clickhouse-контейнера (511 МБ) как оценку на один узел того же типа.

Координатор (Keeper или ZooKeeper) не поднимал — оценка по типовым значениям, не измерение:

clickhouse-keeper (встроен в бинарник ClickHouse, без JVM) — лёгкий, в покое обычно ≈ 100–150 МБ.
ZooKeeper (как в clickhouse-learning-cluster/docker-compose.yml: образ zookeeper:3.9.3, JVM, без явного ограничения кучи) — тяжелее и менее предсказуем, в покое обычно ≈ 250–400 МБ, может расти без явного лимита -Xmx.

Для учебного стенда на 16-гигабайтном ноутбуке разумнее взять clickhouse-keeper: он легче по памяти и не тянет отдельную технологию (JVM) только ради координации — для менти это и проще как для памяти, так и для понимания.

2×1 (2 шарда, без реплик)

Добавка: +1 узел ClickHouse (511 МБ) + 1 координатор.

с keeper: +511 + ~130 ≈ +0,64 ГБ → итого ≈ 4,0 ГБ
с ZooKeeper: +511 + ~325 ≈ +0,84 ГБ → итого ≈ 4,2 ГБ

2×2 (2 шарда × 2 реплики = 4 узла ClickHouse)

Добавка: +3 узла ClickHouse (3 × 511 МБ) + 1 координатор.

с keeper: +1533 + ~130 ≈ +1,66 ГБ → итого ≈ 5,0 ГБ
с ZooKeeper: +1533 + ~325 ≈ +1,86 ГБ → итого ≈ 5,2 ГБ

Сводка по бюджету ноутбука 16 ГБ (WSL2)

По умолчанию WSL2 отдаёт себе примерно половину физической памяти хоста, то есть на 16-гигабайтном ноутбуке это около 8 ГБ (если менти не менял .wslconfig). При явно увеличенном лимите берём 12 ГБ. Windows и браузер на хосте забирают память из этого же физического пула, но не из бюджета WSL напрямую — они снижают запас, только если общий объём ОЗУ хоста прижат к пределу.

Топология	Память стенда	Запас при бюджете WSL 8 ГБ	Запас при бюджете WSL 12 ГБ	Вывод
Текущий стенд (1 узел CH)	≈ 3,4 ГБ	≈ 4,6 ГБ	≈ 8,6 ГБ	помещается с большим запасом
2×1 + keeper	≈ 4,0 ГБ	≈ 4,0 ГБ	≈ 8,0 ГБ	помещается свободно
2×2 + keeper	≈ 5,0 ГБ	≈ 3,0 ГБ	≈ 7,0 ГБ	помещается, но впритык при бюджете 8 ГБ

Выводы:

2×1 (2 шарда без реплик) помещается свободно при любом разумном бюджете WSL2 (8 или 12 ГБ). Это безопасный выбор для ментиного ноутбука по умолчанию.
2×2 (4 узла ClickHouse) технически помещается, но при дефолтном бюджете WSL2 (~8 ГБ) запас становится тесным (~3 ГБ). Реальная нагрузка — запросы, ETL-прогон в Airflow, отрисовка дашборда в Superset, параллельный генератор трафика — может съесть этот запас почти полностью. Топология 2×2 комфортна только если у менти увеличен лимит WSL2 (например, до 12 ГБ через .wslconfig); на дефолтных настройках — рискованно.
Во всех случаях координатор стоит брать clickhouse-keeper, а не отдельный ZooKeeper — экономит память и не добавляет менти лишнюю технологию для изучения.
Все числа — по памяти в покое. Не проверял пиковое потребление под реальными запросами и параллельным генератором трафика — это отдельная зона риска, если 2×2 пойдёт в работу.

Как мерил "второй узел" и координатор — метод

Не поднимал реальный второй узел ClickHouse или ZooKeeper — так как по условию задачи разрешены docker-операции только над текущим demo-стендом. Оценка сделана как:

второй узел ClickHouse = память измеренного узла (тот же образ и конфиг);
координатор = типовые значения для keeper/ZooKeeper (не измерение).

Если нужна точная цифра по координатору — можно измерить на ~/sources/clickhouse-learning-cluster (там уже есть готовый docker-compose с ZooKeeper), это отдельная небольшая задача.

*Резолюция (дословный перенос с GitHub, автор dementev-dev):* # Ресурсный бюджет стенда на 16 ГБ (issue #12) Кратко: замерил память полного стенда (11 контейнеров), прикинул добавку второго узла ClickHouse и координатора (Keeper/ZooKeeper), сравнил с бюджетом WSL2 на ноутбуке 16 ГБ. ## Как мерил 1. Поднял полный стенд: `make up` (10 сервисов) + Superset (уже был поднят) = 11 контейнеров. 2. Дал 2–3 минуты устояться, снял `docker stats --no-stream` дважды с разницей в минуту — цифры не менялись, стенд стабилен в состоянии покоя (без активного ETL и без генератора живого трафика). 3. Прогнал `docker system df` для диска. Важная оговорка: это память в состоянии покоя (idle). Во время реальных запросов, ETL-прогона в Airflow или отрисовки дашборда в Superset потребление памяти может быть заметно выше. Ниже — оценка "снизу", не пиковая нагрузка. ## Память по контейнерам (стенд в покое) | Контейнер | Память | Роль | |---|---|---| | kafka | 937 МБ | брокер сообщений | | airflow-webserver | 764 МБ | веб-интерфейс Airflow | | airflow-scheduler | 416 МБ | планировщик DAG'ов | | clickhouse | 511 МБ | основное хранилище (DWH) | | kafka-ui | 341 МБ | веб-интерфейс для Kafka | | superset | 197 МБ | BI-дашборды | | postgres-metadata | 100 МБ | метабаза Airflow/Superset | | grafana | 91 МБ | мониторинг-дашборды | | statsd-exporter | 13 МБ | мост метрик Airflow → Prometheus | | prometheus | 40 МБ | сбор метрик | | kafka-exporter | 8 МБ | метрики Kafka для Prometheus | | **Итого (11 контейнеров)** | **≈ 3,4 ГБ** | | Генератор живого трафика (`generator`, профиль `live-generator`) в замер не попал — он не поднимается командой `make up`. Если менти параллельно гоняет генератор, добавится ещё немного памяти сверху (отдельно не мерил). CPU у всех контейнеров в покое был низким (в основном до 1–4%) — по процессору стенд не узкое место, узкое место — память. ## Диск (докладом, не основной вопрос) `docker system df` на этой машине показывает много образов от посторонних проектов — они не в счёт. Только для стенда: - образы (свои, без пересечений с чужими) — примерно 2,5–2,7 ГБ; - volumes: `clickhouse-data` ≈ 194 МБ, `kafka-data` ≈ 1,6 ГБ (объём зависит от того, сколько данных прогнали через Kafka — сейчас раздутый после предыдущих сессий), `pgmeta` ≈ 79 МБ, `grafana_lib` ≈ 25 МБ. Диск на ноутбуке 16 ГБ обычно не проблема (сотни гигабайт свободно), поэтому дальше в отчёте — только память. ## Добавка: второй узел ClickHouse + координатор Взял память замеренного `clickhouse`-контейнера (511 МБ) как оценку на один узел того же типа. Координатор (Keeper или ZooKeeper) не поднимал — оценка по типовым значениям, не измерение: - **clickhouse-keeper** (встроен в бинарник ClickHouse, без JVM) — лёгкий, в покое обычно ≈ 100–150 МБ. - **ZooKeeper** (как в `clickhouse-learning-cluster/docker-compose.yml`: образ `zookeeper:3.9.3`, JVM, без явного ограничения кучи) — тяжелее и менее предсказуем, в покое обычно ≈ 250–400 МБ, может расти без явного лимита `-Xmx`. Для учебного стенда на 16-гигабайтном ноутбуке разумнее взять **clickhouse-keeper**: он легче по памяти и не тянет отдельную технологию (JVM) только ради координации — для менти это и проще как для памяти, так и для понимания. ### 2×1 (2 шарда, без реплик) Добавка: +1 узел ClickHouse (511 МБ) + 1 координатор. - с keeper: +511 + ~130 ≈ **+0,64 ГБ** → итого ≈ **4,0 ГБ** - с ZooKeeper: +511 + ~325 ≈ **+0,84 ГБ** → итого ≈ **4,2 ГБ** ### 2×2 (2 шарда × 2 реплики = 4 узла ClickHouse) Добавка: +3 узла ClickHouse (3 × 511 МБ) + 1 координатор. - с keeper: +1533 + ~130 ≈ **+1,66 ГБ** → итого ≈ **5,0 ГБ** - с ZooKeeper: +1533 + ~325 ≈ **+1,86 ГБ** → итого ≈ **5,2 ГБ** ## Сводка по бюджету ноутбука 16 ГБ (WSL2) По умолчанию WSL2 отдаёт себе примерно половину физической памяти хоста, то есть на 16-гигабайтном ноутбуке это около **8 ГБ** (если менти не менял `.wslconfig`). При явно увеличенном лимите берём **12 ГБ**. Windows и браузер на хосте забирают память из этого же физического пула, но не из бюджета WSL напрямую — они снижают запас, только если общий объём ОЗУ хоста прижат к пределу. | Топология | Память стенда | Запас при бюджете WSL 8 ГБ | Запас при бюджете WSL 12 ГБ | Вывод | |---|---|---|---|---| | Текущий стенд (1 узел CH) | ≈ 3,4 ГБ | ≈ 4,6 ГБ | ≈ 8,6 ГБ | помещается с большим запасом | | 2×1 + keeper | ≈ 4,0 ГБ | ≈ 4,0 ГБ | ≈ 8,0 ГБ | помещается свободно | | 2×2 + keeper | ≈ 5,0 ГБ | ≈ 3,0 ГБ | ≈ 7,0 ГБ | помещается, но впритык при бюджете 8 ГБ | **Выводы:** - **2×1 (2 шарда без реплик) помещается свободно** при любом разумном бюджете WSL2 (8 или 12 ГБ). Это безопасный выбор для ментиного ноутбука по умолчанию. - **2×2 (4 узла ClickHouse) технически помещается**, но при дефолтном бюджете WSL2 (~8 ГБ) запас становится тесным (~3 ГБ). Реальная нагрузка — запросы, ETL-прогон в Airflow, отрисовка дашборда в Superset, параллельный генератор трафика — может съесть этот запас почти полностью. Топология 2×2 комфортна только если у менти увеличен лимит WSL2 (например, до 12 ГБ через `.wslconfig`); на дефолтных настройках — рискованно. - Во всех случаях координатор стоит брать **clickhouse-keeper**, а не отдельный ZooKeeper — экономит память и не добавляет менти лишнюю технологию для изучения. - Все числа — по памяти в покое. Не проверял пиковое потребление под реальными запросами и параллельным генератором трафика — это отдельная зона риска, если 2×2 пойдёт в работу. ## Как мерил "второй узел" и координатор — метод Не поднимал реальный второй узел ClickHouse или ZooKeeper — так как по условию задачи разрешены docker-операции только над текущим demo-стендом. Оценка сделана как: - второй узел ClickHouse = память измеренного узла (тот же образ и конфиг); - координатор = типовые значения для keeper/ZooKeeper (не измерение). Если нужна точная цифра по координатору — можно измерить на `~/sources/clickhouse-learning-cluster` (там уже есть готовый docker-compose с ZooKeeper), это отдельная небольшая задача.

ddmitry added a new dependency 2026-07-29 20:40:29 +03:00

#14 Кластер: где живёт опыт менти и какая топология

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Blocks

#14 Кластер: где живёт опыт менти и какая топология

ddmitry/clickstream-ch-kafka-superset-demo

Reference: ddmitry/clickstream-ch-kafka-superset-demo#12