Cloudflare optimizes 1.1.1.1 DNS memory usage
Cloudflare 为 1.1.1.1 瘦身：不换硬件省下 100TB 内存，查询延迟降低 19%
The optimization reduces memory costs for Cloudflare's 1.1.1.1 DNS service, which is freely available globally and often used as an alternative to local DNS providers.
Cloudflare optimized its Big Pineapple platform's DNS cache data structures, releasing approximately 100 TB of RAM memory. The platform stores over 250 billion DNS cache entries at any time. The optimization reduced query latency by 19% without requiring new hardware. Cloudflare implemented the changes by restructuring Rust-based data structures, including replacing Vec and String with Box<[T]> and Box<str>.
Cloudflare 为 1.1.1.1 瘦身：不换硬件省下 100TB 内存，查询延迟降低 19%
IT之家 8 月 29 日消息，Cloudflare 昨日发布博客，称其通过对旗下 Big Pineapple 平台的 DNS 缓存数据结构进行优化，成功释放了约 100 TB 的内存（RAM）资源。 Big Pineapple 是 Cloudflare 旗下支撑 1.1.1.1、Gateway DNS、DNS Firewall、AS112 等多项 DNS 服务的平台。该平台在任何时刻均存储超过 2500 亿条 DNS 缓存条目。在这一规模下，每条缓存记录哪怕只多占用 1 字节，整个集群也会额外消耗超过 250GB 内存。 Cloudflare 强调，此次优化并非依赖新硬件，而是完全通过对 Rust 语言编写的数据结构进行重构实现。 首先大家要知道，DNS 缓存由键值对（Key-Value Pairs）组成。键用于标识查询的域名、记录类型、认证状态等信息（例如 ABC.com + A 记录）；值则保存 DNS 响应的网络数据、权威和附加记录，以及创建时间、TTL（IT之家注：Time to Live，即存活时间）和命中次数等元数据。 Cloudflare 优化首先针对 Rust 中 Vec 和 String 的内存开销展开。由于 DNS 响应写入缓存后不会继续修改，Vec 用于动态扩容的 capacity 字段实际上已经没有必要。Cloudflare 因此将相关结构替换为 Box<[T]> 和 Box<str>，减少每个字段 8 字节的开销，同时避免为后续扩容预留额外空间。 每个缓存条目中共有 8 个相关的 Vec 和 String 字段，这一调整理论上可使每条记录减少 64 字节。按照超过 2500 亿条缓存记录计算，仅这一项优化带来的累计节省就超过 15TB。 Cloudflare 随后减少了 DNS 响应中多个列表产生的指针开销。原本数据、权威和附加记录分别存储在不同列表中，现在改为使用单个列表，并通过偏移量标记不同区域的起始位置。由于 DNS 记录数量可以使用 u16 表示，相关字段从指针和长度信息改为更小的偏移量，每个缓存条目又节省了 28 字节。 此外，Cloudflare 还针对 DNS 记录中的 owner 字段进行了优化。多数情况下，记录所属域名与用户查询的域名完全相同，因此缓存时无需重复保存。只有 CNAME 等情况下记录所属域名不同，才会额外保存完整域名。读取缓存时，如果 owner 字段为空，则直接使用缓存键中的查询域名恢复。 Cloudflare 还调整了 Rust 枚举 enum 的存储方式。原有 RecordData 枚举需要按照最大成员 NAPTR 的大小分配空间，导致常见的 A 和 AAAA 记录也要承担大量未使用的空间。由于 A、AAAA 记录占全部流量的 80% 以上，这种设计造成了明显浪费。 优化后，Cloudflare 将较大的 TXT、NAPTR、SVCB 等枚举成员放入堆内存，而 A、AAAA 等体积较小且常见的记录继续直接存储。这样可以让 A 记录每条节省 120 字节。不过，单独进行堆分配也会带来分配器开销和内存局部性下降等问题，因此 Cloudflare 随后继续调整了数据布局。 最终，Cloudflare 将 DNS 记录的数据部分直接保存为连续的原始字节，而不再为每种记录建立单独的解析后对象。每条记录由长度信息和原始数据组成，并集中存储在一个 Box<[u8]> 中。 这种方式取消了此前每个记录对应的枚举和独立堆分配，同时让数据连续排列，有利于 CPU 缓存命中。对于 A、AAAA、TXT 以及 DNSSEC 记录，生成 DNS 响应时可以直接复制已经编码的数据，无需重新逐字段序列化。CNAME、NS、MX、SOA 等包含域名的记录仍需要解析，以便应用 DNS 名称压缩。 Cloudflare 测试显示，这种数据布局使缓存查询延迟进一步降低约 5%。由于缓存写入使用可重复利用的临时缓冲区，记录数据通常无需反复扩容，这一操作还使缓存插入吞吐量单独提升了 13%。 据介绍，这些优化已于 2026 年 5 月 18 日开始逐步部署，并于 7 月 6 日完成在所有相关服务中的推广。生产环境数据显示，实例内存使用量在不同阶段持续下降。在 p99 情况下，单实例常驻内存从 9.3GB 降至 5.3GB，减少 43%；p90 则从 6.5GB 降至 3.8GB，减少 42%，缓存更满的实例省得更多。 基准测试中，这 5 项优化将单条缓存记录的内存占用从 953 字节降至 420 字节，总计减少 56%；每条记录对应的内存分配量则从 1.1KB 降至 461 字节，减少 58%。缓存插入吞吐量从每秒 62.5 万条提高至 89.3 万条，提升 43%；缓存查询延迟从 828 纳秒降至 670 纳秒，降低 19%。 在生产环境中，由于常驻内存还包括缓存以外的进程数据，因此实际降幅小于单条缓存记录的基准测试结果。所有优化完成并趋于稳定后，Cloudflare 整个服务集群的工作集内存约减少 100TB。 Cloudflare 表示，后续计划利用释放出来的内存扩大 DNS 缓存容量，同时不增加整体内存使用量，以提高缓存命中率并减少向上游 DNS 服务器发起的查询请求。
