Hacker News Digest

Инженеры Render обнаружили 7 TiB памяти, которая простаивала в их Kubernetes-класторе из-за неэффективного использования namespace'ов. Проблема заключалась в том, что daemonset'ы (особенно Calico для сетевой конфигурации и Vector для сбора логов) выполняли listwatch операций для namespace'ов на каждом узле. Это создавало огромную нагрузку на apiserver и потребляло значительные ресурсы, так как количество namespace'ов у Render достигло аномально высокого уровня по сравнению с другими кластерами.

Команда уже оптимизировала Calico, сотрудничая с разработчиками проекта, и обнаружила аналогичную проблему с Vector. Оказалось, Vector отслеживал namespace'ы только для проверки принадлежности pod'ов пользовательским namespace'ам. Инженеры нашли способ обойти эту необходимость, что позволило освободить колоссальные 7 TiB памяти. Это решение подчеркивает важность масштабирования не только по количеству узлов или pod'ов, но и по namespace'ам, которые могут стать скрытым узким местом в инфраструктуре.

• В обсуждении поднимается вопрос о том, что 1.2 ТБ памяти используется только для логов, что вызывает удивление и критику.
• Участники обсуждают, что такое использование ресурсов неэффективно и может быть улучшено, особенно если учесть, что в Kubernetes ключи и метки могут быть оптимизированы.
• Обсуждается, что вместо использования больших строковых ключей, можно было бы использовать UUID или другие уникальные идентификаторы, что сократит использование памяти и улучшит производительность.
• Участники также обсуждают, что вместо того, чтобы хранить логи в таком виде, можно было бы использовать встроенные инструменты для сбора и хранения логов, что было бы более эффективно.

Геокодио перешло с MariaDB на ClickHouse, Kafka и Vector для обработки миллиардов запросов. Исходная система на MariaDB с движком TokuDB не справлялась с нагрузкой: токизация базы не обновлялась с 2021 года, производительность падала с ростом данных, а запросы к миллиардам записей приводили к таймаутам.

Новая архитектура распределяет поток данных через Kafka, который направляет их в ClickHouse для аналитики в реальном времени и долгосрочного хранения. Vector агрегирует данные перед загрузкой, что значительно ускоряет обработку.

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

• Основной вывод: авторы обсуждают, как правильно организовать поток данных от источника к ClickHouse, используя Kafka, Vector или Redis в качестве буфера.
• Практика: вместо того чтобы писать в ClickHouse напрямую, они используют Kafka как очередь, а затем Vector для буферизации.
• Архитектура: ClickHouse не предназначен для очень больших объемов вставки, и поэтому требуется внешняя система буферизации.
• Альтернативы: обсуждаются такие варианты как async insert в ClickHouse, использование Redis вместо Kafka, или применение встроенной функции async insert в ClickHouse.

В Wild-линковщике для Rust применяют несколько продвинутых техник оптимизации параллельной работы. Например, используют split_off_mut для безопасного разделения мутабельных срезов Vec<SymbolId> между потоками, что позволяет обрабатывать символы каждого объекта параллельно без блокировок, сохраняя кэш-локальность.

Для инициализации вектора без задержек на основном потоке задействуют крейт sharded-vec-writer: предварительно аллоцируют память, разбивают её на сегменты по числу символов в объектах и заполняют их параллельно через VecWriter, что ускоряет стартовую фазу.

В случаях, когда требуются случайные записи в общий вектор (например, для обработки дубликатов символов в C++), переходят на атомарные операции. Вместо стабильного, но ограниченного AtomicU32::from_mut_slice (только nightly) или постоянного использования атомиков (что снижает производительность), временно преобразуют &[SymbolId] в &[AtomicSymbolId] через unsafe-конверсию, экономя на издержках синхронизации в основном коде.

• Обсуждаются оптимизации Rust, такие как преобразование Vec в IntoIter и обратно для эффективного повторного использования аллокации, что реализовано в стандартной библиотеке как специальный случай.
• Высказываются предостережения против некоторых "трюков производительности", например, перемещения аллокации в другой поток для освобождения, из-за особенностей работы аллокаторов и сомнительной выгоды.
• Поднимается вопрос о надёжности оптимизаций компилятора (LLVM) в релизных сборках, которые могут меняться между версиями и сложны для верификации, что контрастирует с медленными debug-сборками.
• Отмечается, что многие трюки направлены на обход ограничений borrow checker для получения разрешения на выполнение операций, а не на решение аппаратных задач производительности.
• Обсуждается преимущество Rust в безопасном параллелизме (например, с Rayon) по сравнению с C/C++, где обеспечение потоковой безопасности значительно сложнее.