Cloudflare-მა 1.1.1.1-ის DNS ქეშის ოპტიმიზაციით 100 ტერაბაიტი მეხსიერება დაზოგა

Cloudflare-ის ინჟინერებმა ხუთი თანმიმდევრული ოპტიმიზაციის შედეგად DNS ქეშის მეხსიერების მოხმარება ნახევარზე მეტად შეამცირეს. კომპანიის ბლოგზე 27 აგვისტოს გამოქვეყნებული მასალა ეხება Big Pineapple-ს — პლატფორმას, რომელზეც მუშაობს 1.1.1.1-ის საჯარო რეზოლვერი, ასევე Gateway DNS, DNS Firewall და AS112.

250 მილიარდი ჩანაწერის ქეში

Big Pineapple ერთდროულად ინახავს 250 მილიარდზე მეტ DNS ქეშის ჩანაწერს. რადგან თითოეული ჩანაწერი ასობით მონაცემთა ცენტრში არსებობს, ერთი დახარჯული ბაიტიც კი ფლოტის მასშტაბით 250 გიგაბაიტზე მეტ მეხსიერებას ნიშნავს. ქეშში ყველა ელემენტი გასაღები-მნიშვნელობის წყვილია: გასაღები განსაზღვრავს, რა იყო მოთხოვნილი (სახელი, ჩანაწერის ტიპი, ავთენტიფიკაციის დროშა, ტეგი), მნიშვნელობა კი თავად პასუხს ინახავს — answer, authority და additional სექციებს, ასევე მეტამონაცემებს: შექმნის დრო, მოხვედრების მთვლელი და TTL.

ქეშის ზომა მონაცემთა ცენტრის მიხედვით იცვლება. როცა გამოიყენება EDNS Client Subnet (ECS), ავტორიტეტული სერვერები კლიენტის ქსელის მიხედვით სხვადასხვა პასუხს აბრუნებენ, ამიტომ Cloudflare ერთი და იმავე მოთხოვნის რამდენიმე ვერსიას ინახავს.

ხუთი ცვლილება შენახვის სტრუქტურაში

გუნდმა ეფექტი შეამოწმა წარმოების ტრაფიკის მსგავსი შემთხვევითი ჩანაწერებით: 56% A, 25% AAAA და 19% TXT, თითო ელემენტზე ერთიდან ოთხამდე ჩანაწერი.

Vec-ისა და String-ის Box<[T]>-ით და Box<str>-ით ჩანაცვლება აუქმებს capacity-ის ველს და ზრდისთვის დაცულ სივრცეს — ეს 8 ბაიტია ველზე, 64 ბაიტი ჩანაწერზე და ფლოტის მასშტაბით 15 ტერაბაიტზე მეტი. answer, authority და additional სექციების სამი ცალკე სიის ნაცვლად ერთ სიაში 2-ბაიტიანი ოფსეტებით შენახვა კიდევ 28 ბაიტს ზოგავს. ჩანაწერების უმეტესობაში owner მოთხოვნილ დომენს ემთხვევა, ამიტომ Cloudflare ახლა ამ ველს აღარ ინახავს და სახელს კითხვის დროს ქეშის გასაღებიდან აღადგენს.

დანარჩენი ორი ცვლილება Rust-ის enum-ების ზომას ეხება. enum-ად შენახული ჩანაწერის მონაცემები ყოველთვის ყველაზე დიდი ვარიანტის ზომისაა — NAPTR 144 ბაიტი — მაშინ როცა A ჩანაწერს მხოლოდ 4 ბაიტი სჭირდება, ამიტომ ჩანაწერთა უმეტესობა 120 ბაიტზე მეტს კარგავდა. დიდი ვარიანტების heap-ზე გატანამ პრობლემა მოაგვარა, მაგრამ დასძინა ალოკატორის დამრგვალება და მიმოფანტული ალოკაციები. ბოლო ნაბიჯი ჩანაწერის მონაცემებს wire-ფორმატის ნედლ ბაიტებად ინახავს ერთ ბუფერში 2-ბაიტიანი სიგრძის პრეფიქსებით — ეს აღადგენს ლოკალურობას და ჩანაწერთა უმეტესობა პასუხში პირდაპირი კოპირებით ხვდება.

შედეგები წარმოებაში

ბენჩმარკებში ერთი ჩანაწერის მოცულობა 953 ბაიტიდან 420 ბაიტამდე შემცირდა (−56%), ალოკაციები კი 1.1 კილობაიტიდან 461 ბაიტამდე (−58%). ჩასმის სიჩქარე 625 000-დან 893 000 ჩანაწერამდე წამში გაიზარდა (+43%), ძებნის დაყოვნება 828 ნანოწამიდან 670-მდე დაეცა (−19%).

ცვლილებები 2026 წლის 18 მაისიდან 6 ივლისამდე ეტაპობრივად დაინერგა. p99-ზე ერთი ინსტანციის რეზიდენტული მეხსიერება 9.3 გიგაბაიტიდან 5.3 გიგაბაიტამდე (−43%) შემცირდა, p90-ზე — 6.5-დან 3.8 გიგაბაიტამდე (−42%). ფლოტის საერთო სამუშაო მეხსიერება დაახლოებით 100 ტერაბაიტით ნაკლებია — დაახლოებით იმდენი, რამდენიც Cloudflare-ის Gen 13 სერვერის 130 ერთეულს აქვს. კომპანია გეგმავს, გამოთავისუფლებული მეხსიერება ქეშის ტევადობის გაზრდას მოახმაროს, რაც მოხვედრების მაჩვენებელს გააუმჯობესებს და ზემოთა მოთხოვნების რაოდენობას შეამცირებს.