Cloudflare сэкономила 100 терабайт памяти, оптимизировав DNS-кэш 1.1.1.1
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
Инженеры Cloudflare сократили объём памяти, занимаемый каждым элементом DNS-кэша, более чем на 50% благодаря пяти последовательным оптимизациям. Это освободило около 100 терабайт оперативной памяти по всей инфраструктуре — эквивалент 130 серверов Gen 13. При этом скорость работы кэша выросла: пропускная способность увеличилась на 43%, а задержка при поиске снизилась на 19%. В статье подробно разбираются технические приёмы: замена Vec на Box<[T]>, объединение списков записей, отказ от хранения владельца записи, упаковка вариантов перечислений и хранение записей в wire-формате.
При таком масштабе трата одного лишнего байта на запись обходится более чем в 250 гигабайт памяти по всей инфраструктуре.
- lpapez
Это правильный способ поставлять программное обеспечение. Сначала создайте работающий продукт, проверьте идею, стабилизируйте бизнес, начните получать прибыль, и только потом можно оптимизировать расходы. На самом деле оптимизация — это самая лёгкая часть процесса, потому что в этой ветке HN много экспертов по системному программированию, которые считают такие оптимизации тривиальными.
- irdc
Вот почему системное программирование всё ещё имеет значение. Похоже, они упускают очевидную оптимизацию: размещать данные записи сразу после элементов CacheEntry вместо отдельного выделения памяти. Но, возможно, это говорит во мне программист на C, и в Rust это не так просто.
- BikiniPrince
Забавная вещь насчёт Cloudflare. У меня есть скрипт для прогрева DNS, который использует их топ-1000 или топ-10000 адресов. Когда мой мастер запускается, он прогревает весь кэш. Всё остальное использует memcache, так что кластер nice and toasty. Насколько я знаю, никто больше не публикует статистику по доменам, как они.
- strenholme
В моём MaraDNS я агрессивно оптимизировал использование памяти для записей чёрного списка, выделяя один большой malloc() для памяти записей, а затем проходя по этому блоку памяти для поиска потенциально заблокированных записей. Когда я использовал один malloc() на запись, большой чёрный список занимал 237 мегабайт памяти. Тот же список после оптимизации с одним malloc() занимал всего 9,5 мегабайт. https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...
- vinkelhake
Это довольно стандартные подходы к снижению использования памяти. Я не могу не думать, что подход с объединением нескольких отдельных списков в один в некотором роде подрывает гарантии безопасности Rust. Если раньше у вас было три отдельных объекта Vec, Rust гарантировал, что вы не выйдете за границы. Теперь, когда вы помещаете все эти объекты в один Vec и полагаетесь на смещения, вы открываете дверь для выхода за пределы этих подмассивов без паники. Это мелочь, и она не отменяет оптимизацию, но меня удивляет, что статья об этом не упомянула.
- ManBeardPc
Структура Record содержит rtype и data, где RecordData — это тег-объединение. Разве они не всегда синхронизированы? Я не эксперт по DNS, просто интересно, избыточно ли это или есть причина, по которой оба присутствуют. Теперь это уже не важно, если они хранят это в сериализованном виде, но мне было бы интересно, почему было так.
- superze
Сколько это в евро или мы теперь измеряем деньги в оперативке?
- bhouston
У меня были проблемы с использованием публичного Wi-Fi, когда я переопределяю DNS-сервер на MacBook на 1.1.1.1 или 8.8.8.8. Я думаю, это потому, что captive-порталы требуют кастомного разрешения имени captive.apple.com. И внешние DNS-серверы не разрешат его правильно на страницу авторизации локального шлюза.