Hacker News Digest

Статья разбирает, как структуры данных влияют на производительность Go-программ под современными CPU. Автор подчеркивает, что чтение из оперативной памяти в 60 раз медленнее, чем из кэша L1, и что ложный обмен (false sharing) между ядрами может убить производительность. Показано, как добавление 56-байтовой прокладки между полями структуры устраняет проблему и ускоряет код в 6-10 раз. Другой совет — разделять «горячие» и «холодные» данные и использовать структуры, оптимизированные под кэш-линии. Показано, как профилировать кэш-промахи через perf и как тестировать эффективность структур данных.

• False sharing и cache-line padding в Go приводят к 10-кратному ускорению при использовании структур, разделённых на разные ядра, но требуют ручного управления выравниванием и размером кэш-линии.
• Компилятор Go не переупорядочивает поля структур и не вставляет паддинг, что делает невозможным автоматическое устранение false sharing без кода, что ограничивает оптимизации только ручными методами.
• Пользователи отмечают, что большинство описанных приёмов применимы к другим языкам и что современные компиляторы должны бы справляться с большинством этих проблем автоматически, но в то же время признают, что для низкоуровневой оптимизации лучше подойдут другие языки и инструменты.

Оптимизация 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 виртуальных машин и размещении целого стойка в одном процессоре.