Hacker News Digest

Оптимизация ClickHouse для процессоров Intel с ультра-высоким числом ядер

Авторы: Цзебин Сань, Чжиго Чжоу, Ваньян Го, Тьянью Ли

Гостевой пост от инженеров по оптимизации производительности из Intel Shanghai.

Современные процессоры Intel достигают беспрецедентного числа ядер: до 128 P-ядер на сокет в Granite Rapids и 288 E-ядер в Sierra Forest. Многосокетные системы могут иметь более 400 ядер. Тенденция «больше ядер, а не выше тактовая частота» обусловлена физическими ограничениями и проблемами энергопотребления.

Для аналитических баз данных, таких как ClickHouse, большое количество ядер представляет как возможность, так и сложную задачу. Хотя теоретически больше ядер означают больше параллельной мощности, большинство СУБД не могут полностью использовать аппаратные ресурсы. Проблемы параллельной обработки, такие как конфликты блокировок, когерентность кэша, неоднородный доступ к памяти (NUMA), пропускная способность памяти и накладные расходы на координацию, усугубляются с ростом числа ядер.

Оптимизация для ультра-высокого числа ядер

За последние три года мы анализировали и оптимизировали масштабируемость ClickHouse на процессорах Intel Xeon с большим числом ядер. С помощью инструментов профилирования (perf, emon, Intel VTune) мы исследовали все 43 запроса ClickBench на серверах с ультра-высоким числом ядер, выявляли узкие места и оптимизировали ClickHouse.

Результаты впечатляют: отдельные оптимизации ускоряют выполнение запросов в несколько раз, в некоторых случаях до 10x. Среднее геометрическое время выполнения всех запросов стабильно улучшалось на 2–10% для каждой оптимизации. Это демонстрирует, что ClickHouse можно эффективно масштабировать на системах с ультра-высоким числом ядер.

Ключевые проблемы масштабирования

Помимо производительности одного ядра, необходимо решить несколько ключевых задач:

1. Накладные расходы когерентности кэша: Перемещение строк кэша между ядрами требует циклов CPU.
2. Конфликты блокировок: Даже небольшие последовательные участки кода (1%) сильно ограничивают параллелизм по закону Амдала.
3. Пропускная способность памяти: Эффективное использование памяти критично для систем с интенсивной работой с данными.
4. Координация потоков: Стоимость синхронизации потоков растет сверхлинейно с их количеством.
5. Эффекты NUMA: Задержки и пропускная способность памяти различаются для локальной и удаленной памяти в многосокетных системах.

В этом посте summarized наши оптимизации ClickHouse для серверов с ультра-высоким числом ядер.

• Исправление опечатки в заголовке: речь идёт о 288-ядерных серверных процессорах Intel Sierra Forest, а не о "Intel 280".
• Оптимизация ClickHouse под высокоядорные системы: улучшение аллокаторов памяти, борьба с конкуренцией, использование SIMD-фильтрации (ускорение запросов до 35%).
• Обсуждение технических деталей процессоров: отсутствие AVX-512 на E-ядрах Sierra Forest, наличие AVX2 VNNI, сравнение с AMD Zen 4c.
• Проблемы масштабирования: сложности NUMA, contention points на уровне аллокаторов, разделение полосы пропускания памяти.
• Практический опыт использования ClickHouse: высокая эффективность сжатия и скорость агрегации больших данных (миллиарды снэпшотов).
• Критика и предложения: переход с jemalloc на современные аллокаторы (TCMalloc, mimalloc), использование оптимистичного контроля параллелизма.
• Исторический и футуристический контекст: сравнение с устаревшими системами, шутки о запуске 1000 виртуальных машин и размещении целого стойка в одном процессоре.

musl-аллокатор тормозит в 7 раз
Добавь в main.rs:

#[cfg(target_env = "musl")]
#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

и в Cargo.toml:

[target.'cfg(target_env = "musl")'.dependencies]
mimalloc = "0.1"

Проблема — конкуренция потоков за malloc. Чем больше потоков, тем хуже.
Замена аллокатора нужна даже для однопоточных программ: забудешь — потом дорого.

Почему musl? Статика + 2 МБ distroless-контейнер = старые RH и быстрый cold-start.

Кейс: сервер обрабатывал данные в 7 раз медленнее хоста.
Виноват 200 000 контекст-переключений/сек vs 1 200 у glibc.
strace показал 6,7 с в futex у musl против 0,5 с у glibc.

• musl-аллокатор медленен в многопоточных Rust-программах из-за одного глобального замка.
• Альпийские образы компактны, но «размер» ≠ «скорость»; в проде чаще берут Debian/RHEL.
• Замена: jemalloc, mimalloc или Wolfi (glibc, apk, busybox) без смены менеджера пакетов.
• glibc тоже фрагментирует память; MALLOC_ARENA_MAX=jemalloc спасает.
• Новый mallocng musl не решает конкуренцию потоков: цель musl — минимум кода и харднинг, а не perf.