Zašto je prva C++ (m)alokacija uvijek 72 KB?

Misterij iza vaše prve C++ dodjele

Pišete jednostavan C++ program. Jedan novi int. Četiri bajta. Pokrenete strace ili svoj omiljeni memorijski profiler, i tu je — vaš je proces upravo zatražio otprilike 72 KB od operativnog sustava. Ne 4 bajta. Ne 64 bajta. Punih 72 KB. Ako ste ikada zurili u taj broj i pitali se laže li vam vaš alat, niste jedini. Ovo naizgled bizarno ponašanje jedno je od najčešće postavljanih pitanja među C++ programerima koji po prvi put kopaju po unutarnjim dijelovima memorije, a odgovor nas vodi na fascinantno putovanje kroz slojeve koji se nalaze između vašeg koda i stvarnog hardvera.

Što se događa kada nazovete novo

Da biste razumjeli brojku od 72 KB, morate pratiti cijeli lanac dodjele. Kada vaš C++ kod izvrši new int, kompajler to prevodi u poziv operator new, koji na većini Linux sustava delegira malloc iz glibc-a. Ali malloc ne traži izravno kernel za 4 bajta memorije. Kernel radi u stranicama — obično 4 KB na x86_64 — a cijena sistemskog poziva je ogromna u odnosu na jednostavan pristup memoriji. Pozivanje brk() ili mmap() za svaku pojedinačnu dodjelu zaustavilo bi svaki netrivijalni program.

Umjesto toga, glibcov alokator memorije — implementacija nazvana ptmalloc2, koja i sama potječe od klasičnog dlmalloc Douga Leaa — djeluje kao posrednik. Zahtijeva velike blokove memorije od kernela unaprijed, a zatim ih dijeli na manje dijelove prema potrebi vašeg programa. Ovo je temeljni razlog zašto vaša prva dodjela 4-bajta pokreće mnogo veći zahtjev operativnom sustavu. Alokator nije rastrošan. Strateški je.

Seciranje 72 KB: kamo idu bajtovi

Opterećenje početne dodjele dolazi od nekoliko različitih komponenti koje runtime mora inicijalizirati prije nego što vam može dati čak i jedan bajt korisne memorije. Razumijevanje svake komponente objašnjava zašto se broj nalazi tamo gdje pada.

Prvo, glibc-ov malloc inicijalizira glavnu arenu — primarnu knjigovodstvenu strukturu koja prati sva izdvajanja u glavnoj niti. Ova arena uključuje metapodatke za hrpu, pokazivače slobodnog popisa i strukture spremnika za različite veličine dodjele. Alokator proširuje prekid programa putem sbrk(), a početnim proširenjem upravlja interni parametar pod nazivom M_TOP_PAD, koji prema zadanim postavkama iznosi 128 KB ispune. Međutim, stvarni početni zahtjev prilagođen je za poravnanje stranice i postojeću poziciju prijeloma, što često rezultira manjim prvim zahtjevom — koji se obično nalazi blizu brojke od 72 KB na svježe započetom procesu.

Drugo, od glibc 2.26, alokator inicijalizira lokalni cache niti (tcache) prilikom prve upotrebe. Tcache sadrži 64 spremnika (jedan po klasi veličine male dodjele), a svaki može držati do 7 predmemoriranih dijelova. Sam tcache_perthread_struct troši oko 1 KB, ali čin njegovog pokretanja pokreće šire postavljanje arene. Treće, C++ runtime je već izvršio dodjele prije nego što se vaš main() uopće pokrene — statički konstruktori, inicijalizacija međuspremnika iostreama za std::cout i prijatelje, te postavljanje lokalizacije doprinose tom početnom otisku hrpe.

Sustav Arena i zašto je predraspodjela pametna

Odluka da se unaprijed dodijeli znatan dio memorije umjesto da se traži po komadu nije slučajna implementacija. To je namjerni inženjerski kompromis ukorijenjen u desetljećima iskustva u programiranju sustava. Svaki poziv brk() ili mmap() uključuje promjenu konteksta iz korisničkog prostora u prostor jezgre, modifikaciju preslikavanja virtualne memorije procesa i potencijalna ažuriranja tablice stranica. Na modernom hardveru, jedan poziv sustava košta otprilike 100-200 nanosekundi — trivijalno u izolaciji, katastrofalno u razmjerima.

Razmotrite program koji čini 10 000 malih dodjela tijekom inicijalizacije. Bez predraspodjele, to bi značilo 10.000 sistemskih poziva, što bi koštalo otprilike 1-2 milisekunde čistih troškova. S alokatorom temeljenim na areni, prva dodjela pokreće jedan sistemski poziv, a sljedećih 9999 dodjela servisira se u cijelosti u korisničkom prostoru kroz aritmetiku pokazivača i operacije povezane liste — svaka traje otprilike 10-50 nanosekundi. Matematika je nedvosmislena: predraspodjela pobjeđuje po redovima veličina.

72 KB koje vidite pri prvoj dodjeli nisu izgubljena memorija - to je ulaganje u performanse. Alokator se kladi da će vaš program uskoro napraviti više alokacija, au gotovo svakom scenariju stvarnog svijeta ta se oklada obilato isplati. Trošak neiskorištenog virtualnog adresnog prostora u biti je jednak nuli na modernim 64-bitnim sustavima.

Virtualna memorija naspram fizičke memorije: zašto to nije važno

Uobičajena briga programera koji se prvi put susreću s ovakvim ponašanjem je rasipanje resursa. Ako mi trebaju samo 4 bajta, zašto moj program troši 72 KB? Ključni uvid je da virtualna memorija nije fizička memorija. Kada glibc produži prekid programa za 72 KB, kernel ažurira mapiranje virtualne memorije procesa, ali ne podržava odmah te stranice s fizičkim RAM-om. Stvarne fizičke stranice dodjeljuju se na zahtjev putem pogrešaka stranica — tek kada vaš program piše na određenu adresu, kernel mu dodjeljuje stvarnu stranicu memorije.

To znači da iako se virtualna veličina vašeg procesa povećava za 72 KB, njegova veličina rezidentnog skupa (RSS) — količina stvarno potrošene fizičke RAM memorije — povećava se samo za stranice koje stvarno dodirnete. Za jedan novi int, to je obično jedna stranica od 4 KB, plus sve stranice koje metapodaci arene zauzimaju. Preostali virtualni prostor nalazi se tamo, spreman za upotrebu, ne košta ništa osim adresnog prostora — od čega imate 128 TB na 64-bitnom Linux sustavu.

Ova je razlika ključna pri profiliranju i praćenju proizvodnih aplikacija. Ako izrađujete softver koji treba pratiti stvarnu potrošnju resursa — bilo da se radi o SaaS pozadini, mikroservisu ili analitičkom cjevovodu poput onih koji rade na platformama kao što je Mewayz za poslovne operacije — uvijek biste trebali pratiti RSS, a ne virtualnu veličinu. Alati kao što su /proc/[pid]/smaps, valgrind --tool=massif i pmap mogu vam dati točne otiske fizičke memorije umjesto obmanjujućih brojeva virtualne memorije.

Kako različiti dodjeljivači rukuju prvom dodjelom

Brojka od 72 KB specifična je za glibc ptmalloc2. Drugi alokatori rade različite kompromise, a početni troškovi dodjele variraju u skladu s tim. Razumijevanje ovih razlika je vrijedno pri odabiru alokatora za aplikacije osjetljive na performanse.

• jemalloc (koristi ga Facebook, FreeBSD) — koristi granularniju strukturu arene s lokalnim predmemorijama niti. Početni troškovi obično su veći (često 200+ KB), ali pružaju bolje performanse u više niti zbog smanjenog sukoba zaključavanja.
• tcmalloc (Googleov Thread-Caching Malloc) — Dodjeljuje predmemoriju po niti od približno 2 MB prema zadanim postavkama, uz agresivno prethodno dodjeljivanje. Početni režijski troškovi su veći, ali naknadne male dodjele su iznimno brze.
• musl libc's malloc — Koristi puno jednostavniji dizajn temeljen na mmap za sve dodjele. Početni troškovi su minimalni (često samo 4 KB po dodjeli), ali je cijena po dodjeli veća zbog češćih poziva sustava.
• mimalloc (Microsoft) — Koristi dodjelu na temelju segmenta sa segmentima od 64 MB. Prva dodjela pokreće virtualnu rezervaciju od 64 MB (s minimalnim fizičkim angažmanom), razmjenjujući adresni prostor za iznimnu lokalitet i propusnost.

Izbor između ovih alokatora u potpunosti ovisi o vašem radnom opterećenju. Za dugotrajne poslužiteljske aplikacije s velikom višenitnom dodjelom, jemalloc ili tcmalloc obično nadmašuje glibc-ove zadane. Za ugrađene sustave s ograničenom memorijom, muslov jednostavniji pristup može biti poželjniji unatoč nižoj propusnosti. Za većinu stolnih i poslužiteljskih aplikacija opće namjene, početno opterećenje ptmalloc2 od 72 KB predstavlja razumnu zadanu vrijednost koja dobro radi bez podešavanja.

Podešavanje ponašanja početne dodjele

Ako je zadanih 72 KB početno opterećenje zaista problematično za vaš slučaj upotrebe — možda stvarate tisuće kratkotrajnih procesa, od kojih svaki čini samo nekoliko dodjela — glibc pruža nekoliko podesivih putem mallopt() i MALLOC_ obitelji varijabli okruženja.

Parametar M_TOP_PAD kontrolira koliko dodatne memorije alokator zahtijeva osim onoga što je odmah potrebno. Postavljanje na 0 s mallopt(M_TOP_PAD, 0) govori alokatoru da zahtijeva samo ono što je potrebno, značajno smanjujući početne troškove. Parametar M_MMAP_THRESHOLD kontrolira veličinu iznad koje dodjele koriste mmap umjesto arene. M_TRIM_THRESHOLD kontrolira kada se oslobođena memorija vraća u OS. A od glibc 2.26, podesive opcije glibc.malloc.tcache_count i glibc.malloc.tcache_max omogućuju kontrolu ponašanja predmemorije niti.

Međutim, riječ opreza: podešavanje ovih parametara bez pažljive usporedne analize gotovo uvijek pogoršava stvari. Zadane postavke odabrane su na temelju opsežnog profiliranja u stvarnom svijetu i predstavljaju dobro mjesto za veliku većinu radnih opterećenja. Osim ako nemate čvrste dokaze iz proizvodnog profiliranja da su troškovi malloc-a usko grlo — i ako ste izmjerili učinak svojih promjena — ostavite zadane postavke na miru. Preuranjena optimizacija alokatora posebno je podmukao oblik brijanja jakova koji je potrošio bezbrojne inženjerske sate za zanemarivu korist.

Što nas ovo uči o programiranju sustava

Misterij prve dodjele od 72 KB u svojoj je srži lekcija o slojevima apstrakcije. C++ vam daje iluziju da new int dodjeljuje 4 bajta. Jezični standard tako kaže. Vaš mentalni model to kaže. Ali između vašeg koda i hardvera nalazi se hrpa sofisticiranih sustava — C++ runtime, C biblioteka alokator, podsustav virtualne memorije jezgre i hardverski MMU i TLB — svaki dodaje vlastita ponašanja, optimizacije i troškove.

Ovo nije mana. To je cijela poanta sistemskog softvera. Svaki sloj postoji kako bi riješio pravi problem: alokator postoji tako da ne morate upućivati ​​sistemske pozive za svaku dodjelu. Sustav virtualne memorije postoji tako da ne morate izravno upravljati fizičkom memorijom. Rukovatelj greškama stranice postoji tako da se memorija predaje lijeno i učinkovito. Svaki sloj mijenja malu količinu prozirnosti za veliku količinu izvedbe i praktičnosti.

Razvojni programeri koji grade najpouzdanije sustave s najboljim učinkom su oni koji razumiju ove slojeve — ne zato što moraju neprestano razmišljati o njima, već zato što kada se dogodi nešto neočekivano (poput tajanstvene dodjele 72 KB), oni imaju mentalni model da razumiju zašto. Bilo da gradite sustav trgovanja u stvarnom vremenu, pokretač igre ili poslovnu platformu koja opslužuje tisuće korisnika, sposobnost razmišljanja o tome što vaš kod zapravo radi na razini sustava ono je što odvaja kompetentne programere od iznimnih. 72 KB nije greška. To je vaš alokator koji briljantno obavlja svoj posao.