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 դաշտը և աճի համար պահվող heap տարածքը՝ 8 բայթ դաշտի համար, 64 բայթ գրառման համար և ավելի քան 15 տերաբայթ ամբողջ ֆլոտում։ answer, authority և additional բաժինները երեք առանձին ցուցակների փոխարեն մեկ ցուցակում 2-բայթանոց offset-ներով պահելը խնայում է ևս 28 բայթ յուրաքանչյուր գրառման համար։ Գրառումների մեծ մասում owner-ը համընկնում է հարցված դոմենի հետ, ուստի այդ դաշտը այժմ չի պահվում, և անունը ընթերցման պահին վերականգնվում է քեշի բանալիից։

Մյուս երկու փոփոխությունները վերաբերում են 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 տերաբայթով պակաս է՝ մոտավորապես այնքան RAM, որքան ունի Cloudflare-ի Gen 13 սերվերների 130 միավոր։