Cloudflare 優化 1.1.1.1 DNS 快取：Rust 佈局改動釋出約 100 TB RAM（2026）

Cloudflare 剛發表 2026 年最扎實的系統工程文之一：透過調整 Rust 中 DNS 快取項目的記憶體佈局，在支撐 1.1.1.1 的全球機隊上釋出約 100 TB RAM——不必加機器，也沒有用變慢換省記憶體。

在 2026 年 8 月 27 日工程部落格中，Sebastiaan Neuteboom 說明 Big Pineapple（1.1.1.1、Gateway DNS、DNS Firewall、AS112 等共用解析平台）連續五次佈局改動。TechSpot、GIGAZINE 與開發者社群摘要都指向同一組數字：更小的項目、更快的寫入與查詢。

重點一覽

以下把 Cloudflare 原文與後續報導的核心數字收成一表：平台規模、每筆節省、效能提升，以及正式上線窗口。

項目	內容
平台	Big Pineapple — 1.1.1.1 及其他 Cloudflare DNS 服務
規模	機隊同時約 2500 億+ 筆 DNS 快取
每筆佔用	953 → 420 bytes（−56%）
每筆配置量	1.1 KB → 461 bytes（−58%）
機隊釋放 RAM	約 100 TB（約 130 台 Gen 13 伺服器等級）
寫入吞吐	+43%（基準測試 625k → 893k entries/s）
查詢延遲	−19%（828 ns → 670 ns）
實例 p99 記憶體	9.3 → 5.3 GB（−43%）
上線窗口	2026 年 5 月 18 日 – 7 月 6 日

為什麼在 DNS 規模下，幾個 byte 很貴

Big Pineapple 把巨大快取放在記憶體裡。冷啟動時空的，查詢進來後填滿各地點的容量上限，再淘汰較舊或不熱門項目。

在 超過 2500 億 筆並存項目時，每筆多浪費 1 byte，機隊就要多付超過 250 GB RAM。EDNS Client Subnet（ECS）在部分資料中心更明顯：同一查詢名可能因客戶端網路不同而快取多個答案，記憶體壓力更大。

重點很直接：一旦結構是「寫入一次、每秒讀數百萬次」，可成長的 Vec / String 就不再「免費」。

五次 Rust 佈局改動

Cloudflare 沒有重寫整個 resolver，而是收緊快取項目的表示方式——五步，邊上線邊量測。

1. 拿掉用不到的 capacity

快取寫入後不再成長。用 Box<[T]> / Box<str> 取代 Vec / String，去掉 capacity 與過量配置——八個欄位約 64 bytes 結構開銷，外加 heap 浪費。僅此一步估計就省 15+ TB。

2. 更少的 list、更少的指標

Answer / authority / additional 合併成一個 list，用 u16 區段偏移，取代三個獨立 boxed slice——每筆約省 28 bytes，並因旗標打包回收 padding。

3. 可選的 owner 名稱

多數紀錄的 owner 等於查詢名。用 Option，常見路徑從 cache key 重建；只有 CNAME 等分歧才保留 heap 名稱。

4. Box 大型 enum 變體

RecordData 過去依罕見大型類型（如 NAPTR ~136 bytes）定大小。把大型變體 box 出去後，常見 A/AAAA 不再承擔約 144 bytes 的稅。

5. Wire format 位元組

最大收穫：以長度前置的原始 DNS wire bytes 存成連續 Box<[u8]>。多數 A/AAAA/TXT/DNSSEC 可直接 memcpy 進回應，局部性更好，boxing 開銷大幅消失。

基準測試與正式環境結果

Cloudflare 同時做了合成填滿（約 56% A、25% AAAA、19% TXT 替代）與上線期間真實常駐記憶體量測。

指標	之前	之後	變化
每筆淨佔用	953 bytes	420 bytes	−56%
每筆配置量	1.1 KB	461 bytes	−58%
快取寫入吞吐	625,000 /s	893,000 /s	+43%
快取查詢延遲	828 ns	670 ns	−19%
實例記憶體（p99）	9.3 GB	5.3 GB	−43%
實例記憶體（p90）	6.5 GB	3.8 GB	−42%
機隊 working-set RAM	—	−約 100 TB	≈ 130 台 Gen 13

正式環境節省會略低於純每筆推算，因為行程 RSS 還含緩衝與非快取狀態——因此 Cloudflare 兩種數字都公開。

省下的記憶體怎麼用？

Cloudflare 不是為了把 RAM 閒置起來。計畫是在相同記憶體預算下，把空間再投入更大快取容量——提高命中率、減少上游查詢。後續還可能繼續優化快取結構。

對任何記憶體內熱路徑來說：佈局審查的目標往往是容量與延遲一起改善，而不只是帳單變小。

為什麼這則新聞超出 DNS

寫一次的集合

資料建立後不再成長，固定 slice 勝過可成長 vector——在數十億物件下，capacity 與過量配置會累積成真實成本。

罕見大型變體

Enum / union 以最大變體定大小。把罕見巨物 box 出去，常見小案例才能保持密度。

為熱路徑序列化

若熱路徑多半原樣吐出位元組，wire / 序列化緩衝區在記憶體與 CPU 上，可能勝過完整解析後的結構。

同樣直覺也適用於 embedding 快取、feature store、session state 與其他行程內索引——不只遞迴 DNS。

常見問題

若只想快速確認「改了什麼、有沒有變慢、上線多久、100 TB 是單機還是機隊」，可直接看這張對照表。

問題	答案
Cloudflare 優化了什麼？	Big Pineapple（1.1.1.1 等）上 DNS 快取項目的記憶體內佈局。
省 RAM 有沒有變慢？	沒有——基準測試寫入 +43%、查詢延遲 −19%。
正式上線多久？	2026 年 5 月 18 日至 7 月 6 日，分階段發布。
「100 TB」是單機還是機隊？	機隊整體 working-set 下降。

來源

緊貼最新動態

隨時掌握最新新聞與更新