Hacker News Digest

Cloudflare сократил потребление памяти в сервисе Pingora Backend Router на более чем 100 ТБ за счёт оптимизации алгоритма consistent hashing в библиотеке pingora-ketama. Проблема заключалась в том, что для каждого узла хранились полные копии хеш-кольца — структуры данных, используемой для распределения запросов между серверами. При росте числа узлов это приводило к квадратичному росту памяти: каждый новый узел дублировал всё кольцо, что при тысячах серверов и петабайтах RAM становилось неприемлемо дорогим.

Оптимизация заключалась в переходе от полного дублирования кольца к компактному представлению: вместо хранения всех хешей каждого узла, теперь хранится только базовое множество хешей на узел, а при поиске используется эффективный алгоритм сортировки и бинарного поиска по сжатому пространству. Это позволило уменьшить память на узел с O(N) до O(1) относительно числа узлов, сохранив при этом свойства consistent hashing — минимальную переназначенность при добавлении/удалении узлов и равномерное распределение нагрузки. Изменения были внесены как обратно совместимая функция v2 в pingora-ketama, позволяющая逐步 мигрировать без простоев. После полного перехода на новую версию наблюдался резкий спад потребления памяти — подтверждённый метриками — что эквивалентно экономии более 100 ТБ RAM по всему глобальному флоту Cloudflare. Это демонстрирует, как математическая прозорливость и аккуратная реализация в Rust могут превратить, казалось бы, незначительные алгоритмические улучшения в масштабную экономию ресурсов.

Оптимизация Cloudflare имеет смысл только на масштабе их инфраструктуры. Для обычных систем экономия 1% памяти не оправдывает сложность реализации. Спор: Некоторые считают, что оптимизация на 100 ТБ оправдана только из-за масштаба Cloudflare, а для большинства систем это не стоит усилий. Спор: Один участник предлагает заменить consistent hashing на tournament hashing с N битами ключа и wyhash — это сократит использование памяти на 600 ТБ и снизит задержку за счёт O(n) вместо O(n log n). Совет: Использовать B-дерево с суммированием весов узлов и бинарным поиском по хешу, масштабированному на общий вес — это снизит затраты на обновление дерева до ~8 узлов при добавлении/удалении сервера. Совет: Применить сжатие указателей в Rust — удаление по 2 байта с каждого указателя сэкономит сотни гигабайт при большом числе записей. Многие отмечают, что Cloudflare вернулся к качественному, человечески написанному контенту, в отличие от предыдущих постов, написанных ИИ — это воспринимается как позитивный сдвиг. Пользователи подтверждают, что оптимизации хеш-колец и хранения данных важны для крупных систем, где небольшие улучшения приводят к значительной экономии ресурсов. Совет: При небольшом масштабе профилирование и устранение избыточных байтов на запись эффективнее сложных алгоритмических оптимизаций, не протестированных на реальных данных. Спор: Некоторые критикуют статью за преувеличение технической глубины — математика в ней не революционна, а базова для команд, работающих с оптимизацией на уровне дата-центров. Совет: Использовать rendezvous hashing — алгоритм для балансировки нагрузки в прокси-кэшах, который может заменить ketama и сократить память без потери равномерности распределения. Пользователи отмечают, что эпоха изобилия памяти закончилась — рост стоимости RAM и масштаб инфраструктуры заставляют компании возвращаться к глубокой оптимизации, как в прошлом. Спор: Один участник утверждает, что экономия памяти ради снижения затрат не этична, если это приводит к росту цен на оборудование для малого бизнеса и рабочего класса. Совет: В Rust можно использовать структуры с layout-оптимизацией и struct-of-arrays для улучшения кэш-локальности при поиске в хеш-кольце — это снижает задержки без увеличения памяти.

Cloudflare оптимизировала хранение записей в DNS-кэше Big Pineapple, сократив потребление памяти на 100 ТБ без потери производительности. Кэш содержит более 250 млрд записей, и даже экономия одного байта на запись эквивалентна 250 ГБ. Пять последовательных улучшений уменьшили размер одной записи с 953 до 420 байт — на 56% — за счёт устранения избыточности в структурах данных: замена Vec<T> на более компактные типы там, где длина известна или ограничена, оптимизация выравнивания и удаление неиспользуемых полей. Это также снизило количество аллокаций на запись с 1,1 КБ до 461 байт.

Производительность при этом выросла: пропускная способность вставки увеличилась на 43% (с 625 тыс. до 893 тыс. записей/с), а латентность поиска снизилась на 19% (с 828 до 670 нс) благодаря лучшей локальности памяти и меньшему числу операций分配. В продакшене наблюдалось снижение резидентной памяти на 42–43% на перцентилях p90 и p99. Освободившиеся ресурсы планируется использовать для увеличения ёмкости кэша, что повысит коэффициент попаданий и уменьшит нагрузку на апстрим-DNS. Дальнейшие улучшения кэша находятся в исследовании.

Оптимизация памяти на сотнях терабайт требует глубокого понимания структур данных и системного программирования, а не только масштабирования железа, и даёт кратные выигрыши на практике. Экономия даже одного байта на записи критична: в Cloudflare это сэкономило 250 ГБ на миллиардах записей. Одно крупное выделение памяти вместо множества мелких (single malloc) сокращает потребление в 20+ раз (опыт MaraDNS с чёрными списками). Выравнивание полей в Go экономит до 8 байт на объекте, что значимо при миллионах экземпляров. Хранение данных в сериализованном виде вместо разобранных структур улучшает локальность, если основная операция — чтение с повторной сериализацией. Радикальные оптимизации возможны и в прикладных задачах: в игре Wavetale потребление снизили с 20+ ГБ до 3 ГБ. Спорный момент: замена нескольких Vec на один смещённый буфер в Rust технически корректна, но лишает гарантий безопасности границ подсрезок. Советы: - Для DNS-ключей с общими префиксами (com.site.www) подходит radix tree. - Использование Box для указателей избыточно при низком потреблении памяти: 4–8 байт вместо 16. - jemalloc не всегда оптимален для многопоточных нагруженных систем. - Сжатие данных в памяти эффективно при редком декодировании и высокой повторяемости (как домены). - Формат в памяти отличается от сериализованного — компактные структуры эффективнее стандартных языковых объектов. Оптимизация должна быть частью проектирования, а не последним шагом: многие системы становятся избыточными из-за игнорирования масштабируемости на ранних этапах.

Rust Glancer — альтернативный LSP для Rust, разработанный с фокусом на минимальное потребление памяти. Проект реализует полноценный индексирующий движок с поддержкой типовой инференции, trait‑solver (chalk) и большинством стандартных LSP‑действий: переход по определению, подсказки, автодополнение. Ключевая особенность — возможность поддержания индекса после перезапуска, что устраняет повторную индексацию и экономит время. На тестах на MacBook Pro M1 (2020, 8 ГБ RAM) среднее время индексации составило 6 секунд против 7 секунд у rust‑analyzer, а использование RAM оставалось ниже 100 МБ.

В отличие от rust‑analyzer, который опирается на salsa‑базу и rowan‑дерево, вызывающие значительные накладные расходы на память из‑за инкрементального хранения и фрагментации, Glancer использует собственный engine‑as‑subprocess‑model, выравнивает жизненные циклы выделений и шардирует кэш, что позволяет сократить фрагментацию и держать отпечаток памяти в узком диапазоне. Планируется дальнейшее ускорение, улучшение поддержки синтаксиса и расширение функций (code actions, более точная типовая инференция, ограниченный proc‑macro‑подход). Пока проект находится в стадии «daily‑driver», но уже доступен через VS Code‑extension и готовый к самостоятельной установке.

Rust Glancer — альтернатива rust-analyzer, решающая проблему чрезмерного потребления памяти, особенно в крупных проектах. В отличие от rust-analyzer, он сохраняет индекс на диске и загружает его по необходимости, снижая пиковое потребление ОЗУ — критично при ограниченных ресурсах. Пользователи рекомендуют его как полезный компромисс, особенно при нехватке памяти и использовании Neovim с LSP. Автор popzxc отмечает, что приоритезация открытых файлов компенсирует отсутствие инкрементальности, делая подход приемлемым для повседневной работы. Сомнения вызывают: почему rust-analyzer потребляет больше памяти, чем диск-кэш (potamic), и насколько корректен Rust Glancer без формальной спецификации Rust (bip-bop-robot). LSP — общеизвестный термин в Rust-сообществе.