Cloudflare освободила 100 ТБ RAM-памяти, оптимизировав хранение DNS-кэша. — 28 августа 2026 г. в 17:11:00.106
Cloudflare освободила 100 ТБ RAM-памяти, оптимизировав хранение DNS-кэша. Компания Cloudflare рассказала о впечатляющем кейсе, как освободила 100 ТБ RAM-памяти, оптимизировав хранение DNS-кэша. При этом всё сделали за счёт софтовой оптимизации. В каждый момент времени система хранит более 250 млрд записей DNS-кэша. Поэтому даже один лишний байт на запись «весил» для инфраструктуры более 250 ГБ. Инженеры последовательно внесли пять изменений в то, как в памяти хранятся записи кэша. Я коротко опишу каждое: * Замена динамических структур. Вместо Vec<T> и String (которые хранят ещё и информацию о зарезервированной ёмкости) стали использовать Box<[T]> и Box<str>. После попадания в кэш данные не меняются, так что дополнительная память под расширение была не нужна. Только это изменение дало экономию более 15 ТБ. * Объединение массивов. Три отдельных массива записей (answer, authority, additional) свели в один. Вместо полноценных указателей и длин для секций стали использовать двухбайтовые смещения. Это позволило убрать два указателя и две длины, сэкономив ещё 28 байт на запись. * Избавление от дубликатов. В большинстве записей имя владельца (домен) совпадало с тем, что уже было в ключе кэша. Его перестали хранить отдельно в таких случаях - при необходимости имя восстанавливали из ключа. Отдельно имя сохраняли только для особых случаев (например, для записей CNAME). * Работа с enum в Rust. Размер перечисления определяется его самым крупным вариантом. В структуре Cloudflare таким вариантом был NAPTR (он занимал 144 байта), хотя самые частые записи (A - 4 байта, AAAA - 16 байт) требовали куда меньше. Инженеры вынесли крупные варианты в отдельные области памяти (heap-объекты), что заметно уменьшило общий размер enum. * Компактное хранение данных. Вместо разбора записей в отдельные Rust-структуры данные стали помещать в единый Box<[u8]> практически в сетевом формате DNS. Перед каждой записью добавляли двухбайтовую длину. Это сократило число отдельных выделений памяти и улучшило локальность данных для процессорного кэша. Для многих типов записей (A, AAAA, TXT, DNSSEC) это позволило сразу копировать данные в формируемый ответ, не выполняя повторную сериализацию. Результаты: * В тестах средний объём памяти на одну запись сократился с 953 до 420 байт (на 56%), а объём выделяемой памяти - с 1,1 КБ до 461 байта. * В реальной инфраструктуре эффект оказался чуть меньше (потому что в RSS процесса входит не только кэш), но суммарно по всей системе экономия составила около 100 ТБ. Для наглядности: это примерно объём памяти 130 серверов Cloudflare поколения Gen 13. * Производительность не пострадала - наоборот, выросла. Пропускная способность при добавлении записей увеличилась с 625 тыс. до 893 тыс. записей в секунду (на 43%), а задержка поиска снизилась с 828 до 670 нс (на 19%). В production метрики тоже улучшились: p99 по потреблению памяти на экземпляр упал с 9,3 до 5,3 ГБ, а p90 - с 6,5 до 3,8 ГБ. https://blog.cloudflare.com/dns-cache-memory-optimization-1111/