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

Misterija iza vaše prve dodjele C++

Pišete jednostavan C++ program. Jedna nova int. Četiri bajta. Pokrenete strace ili svoj omiljeni memorijski profiler, i eto ga – vaš proces je upravo zatražio otprilike 72 KB od operativnog sistema. Ne 4 bajta. Ne 64 bajta. Punih 72 KB. Ako ste ikada zurili u taj broj i pitali se da li vas je vaš alat lagao, niste sami. Ovo naizgled bizarno ponašanje jedno je od najčešće postavljanih pitanja među C++ programerima koji po prvi put kopaju po unutrašnjosti memorije, a odgovor nas vodi na fascinantno putovanje kroz slojeve koji se nalaze između vašeg koda i stvarnog hardvera.

Šta se događa kada nazovete novo

Da biste razumjeli broj od 72 KB, trebate pratiti cijeli lanac dodjele. Kada vaš C++ kod izvrši new int, prevodilac to prevodi u poziv operatoru new, koji na većini Linux sistema delegira malloc od glibc-a. Ali malloc ne traži direktno od kernela 4 bajta memorije. Kernel radi na stranicama — obično 4 KB na x86_64 — i cijena sistemskog poziva je ogromna u odnosu na jednostavan pristup memoriji. Pozivanje brk() ili mmap() za svaku pojedinačnu dodjelu učinilo bi da se bilo koji netrivijalni program zaustavi.

Umjesto toga, glibc-ov alokator memorije — implementacija nazvana ptmalloc2, koja je sama potekla od klasičnog dlmalloc Douga Lea-a — djeluje kao posrednik. Zahteva velike blokove memorije od kernela unapred, a zatim ih seče na manje delove kako su vašem programu potrebni. Ovo je osnovni razlog zašto vaša prva 4-bajtna alokacija pokreće mnogo veći zahtjev operativnom sistemu. Alokator nije rasipnički. To je strateški.

Seciranje 72 KB: Gdje idu bajtovi

Početni troškovi dodjele dolaze iz nekoliko različitih komponenti koje vrijeme izvođenja mora inicijalizirati prije nego vam može predati čak i jedan bajt upotrebljive memorije. Razumijevanje svake komponente objašnjava zašto se broj nalazi tamo gdje je.

Prvo, glibc-ov malloc inicijalizira glavnu arenu — primarnu knjigovodstvenu strukturu koja prati sve alokacije na glavnoj niti. Ova arena uključuje metapodatke za hrpu, pokazivače slobodne liste i strukture bipa za različite veličine alokacije. Alokator proširuje prekid programa putem sbrk(), a početnom ekstenzijom upravlja interni parametar pod nazivom M_TOP_PAD, koji je zadano na 128 KB dopuna. Međutim, stvarni početni zahtjev je prilagođen za poravnanje stranice i postojeću poziciju prijeloma, što često rezultira manjim prvim zahtjevom — obično se slijeće blizu te brojke od 72 KB u tek započetom procesu.

Drugo, od glibc 2.26, alokator inicijalizira thread-local cache (tcache) pri prvoj upotrebi. tcache sadrži 64 bina (jedan po klasi veličine male alokacije), od kojih svaka može držati do 7 keširanih dijelova. Sam tcache_perthread_struct troši oko 1 KB, ali čin inicijalizacije pokreće širu postavku arene. Treće, C++ vrijeme izvođenja je već izvršilo dodjelu prije nego što se vaš main() čak i pokrene — statički konstruktori, iostream inicijalizacija bafera za std::cout i prijatelje, i postavljanje lokalizacije doprinose tom početnom otisku hrpe.

Sistem arene i zašto je pre-dodjela pametna

Odluka da se unaprijed dodijeli značajan dio memorije umjesto da se zahtijeva podjelom nije slučajnost implementacije. To je namjerni inženjerski kompromis ukorijenjen u decenijama iskustva sistemskog programiranja. Svaki poziv brk() ili mmap() uključuje promjenu konteksta iz korisničkog prostora u prostor kernela, modifikaciju mapiranja virtualne memorije procesa i potencijalna ažuriranja tablice stranica. Na modernom hardveru, jedan sistemski poziv košta otprilike 100-200 nanosekundi – trivijalno u izolaciji, katastrofalno na skali.

Razmotrite program koji pravi 10.000 malih alokacija tokom inicijalizacije. Bez pre-alokacije, to bi značilo 10.000 sistemskih poziva, što bi koštalo otprilike 1-2 milisekunde čistih troškova. Sa alokatorom baziranim na areni, prva alokacija pokreće jedan sistemski poziv, a sljedećih 9.999 alokacija se u potpunosti servisira u korisničkom prostoru kroz aritmetiku pokazivača i operacije povezane liste — svaka traje otprilike 10-50 nanosekundi. Matematika je nedvosmislena: pre-alokacija pobjeđuje po redovima veličine.

Onih 72 KB koje vidite pri prvoj alokaciji nije izgubljena memorija – to je investicija u performanse. Alokator se kladi da će vaš program uskoro izvršiti više alokacija, a u gotovo svakom stvarnom scenariju, ta opklada se odlično isplati. Cena neiskorištenog virtuelnog adresnog prostora je u suštini nula na modernim 64-bitnim sistemima.

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

Uobičajeni problem među programerima koji se po prvi put susreću s takvim ponašanjem je rasipanje resursa. Ako mi treba samo 4 bajta, zašto moj program troši 72 KB? Ključni uvid je da virtuelna memorija nije fizička memorija. Kada glibc produži prekid programa za 72 KB, kernel ažurira mapiranja virtuelne memorije procesa, ali ne podržava te stranice odmah fizičkom RAM-om. Stvarne fizičke stranice se dodjeljuju na zahtjev putem greške stranice — samo 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 stalna veličina skupa (RSS) – količina fizičke RAM memorije koja se stvarno troši – povećava se samo za stranice koje zaista dodirnete. Za jedan novi int, to je obično jedna stranica od 4 KB, plus sve stranice koje metapodaci arene zauzimaju. Preostali virtuelni prostor se nalazi tamo, spreman za upotrebu, ne košta ništa osim adresnog prostora — od čega imate 128 TB na 64-bitnom Linux sistemu.

Ova razlika je kritična pri profiliranju i praćenju proizvodnih aplikacija. Ako pravite softver koji treba da prati stvarnu potrošnju resursa – bilo da se radi o SaaS backendu, mikroservisima ili analitičkim kanalima poput onih koji rade na platformama kao što je Mewayz za poslovne operacije – uvijek biste trebali pratiti RSS umjesto virtualne veličine. Alati kao što su /proc/[pid]/smaps, valgrind --tool=massif i pmap mogu vam dati precizne otiske fizičke memorije umjesto da obmanjuju podatke o virtuelnoj memoriji.

Kako različiti alokatori rukuju prvom dodjelom

Broj od 72 KB specifičan je za glibc-ov ptmalloc2. Drugi alokatori prave različite kompromise, a prema tome variraju i početni troškovi alokacije. Razumijevanje ovih razlika je dragocjeno prilikom odabira alokatora za aplikacije osjetljive na performanse.

• jemalloc (koristi ga Facebook, FreeBSD) — Koristi granularniju strukturu arene s lokalnim kešovima. Početni dodatni 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 (Google-ov Malloc za keširanje niti) — dodjeljuje keš memoriju po niti od približno 2 MB prema zadanim postavkama, sa agresivnom prethodnom dodjelom. Početni troškovi su veći, ali naknadne male alokacije su izuzetno brze.
• musl libc-ov malloc — Koristi mnogo jednostavniji dizajn baziran na mmap za sve alokacije. Početni troškovi su minimalni (često samo 4 KB po alokaciji), ali je trošak po alokaciji veći zbog češćih sistemskih poziva.
• mimalloc (Microsoft) — Koristi dodjelu zasnovanu na segmentima sa segmentima od 64 MB. Prva alokacija pokreće virtuelnu rezervaciju od 64 MB (uz minimalnu fizičku obavezu), adresni prostor za trgovanje za izuzetnu lokaciju i propusnost.

Izbor između ovih alokatora u potpunosti zavisi od vašeg radnog opterećenja. Za dugotrajne serverske aplikacije sa teškom višenitnom alokacijom, jemalloc ili tcmalloc obično nadmašuje glibc-ov default. Za ugrađene sisteme ograničene memorijom, muslov jednostavniji pristup može biti poželjniji uprkos nižoj propusnosti. Za većinu desktop i serverskih aplikacija opće namjene, ptmalloc2 72 KB početni troškovi predstavljaju razumnu zadanu vrijednost koja dobro funkcionira bez podešavanja.

Podešavanje ponašanja početne alokacije

Ako su zadani početni troškovi od 72 KB zaista problematični za vaš slučaj upotrebe — možda pokrećete hiljade kratkotrajnih procesa, od kojih svaki čini samo nekoliko alokacija — glibc pruža nekoliko podešavanja putem mallopt() i MALLOC_ porodice varijabli okruženja.

Parametar M_TOP_PAD kontrolira koliko dodatne memorije alokator zahtijeva iznad onoga što je odmah potrebno. Postavljanje na 0 sa 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 alokacije koriste mmap umjesto arene. M_TRIM_THRESHOLD kontrolira kada se oslobođena memorija vrati u OS. A od glibc 2.26, podešavanja glibc.malloc.tcache_count i glibc.malloc.tcache_max vam omogućavaju da kontrolišete ponašanje predmemorije niti.

Međutim, riječ opreza: podešavanje ovih parametara bez pažljivog benčmarkinga gotovo uvijek pogoršava stvari. Podrazumevane vrednosti su izabrane na osnovu opsežnog profilisanja u stvarnom svetu, i predstavljaju slatko mesto za veliku većinu radnih opterećenja. Osim ako nemate jake dokaze iz proizvodnog profilisanja da su malloc overhead usko grlo — i ako ste izmjerili uticaj svojih promjena — ostavite zadane postavke na miru. Prerana optimizacija alokatora je posebno podmukao oblik brijanja jaka koji je potrošio bezbroj inženjerskih sati uz zanemarljivu korist.

Šta nas ovo uči o sistemskom programiranju

Misterija prve alokacije od 72 KB je, u svojoj srži, lekcija o slojevima apstrakcije. C++ vam daje iluziju da novi int dodjeljuje 4 bajta. Jezički standard tako kaže. Vaš mentalni model tako kaže. Ali između vašeg koda i hardvera nalazi se hrpa sofisticiranih sistema — C++ runtime, C biblioteka alokator, podsistem virtuelne memorije kernela i hardverski MMU i TLB — svaki dodaje svoje ponašanje, optimizacije i nadmetanje.

Ovo nije mana. To je cijela poenta sistemskog softvera. Svaki sloj postoji da bi riješio stvarni problem: alokator postoji tako da ne morate upućivati ​​sistemske pozive za svaku alokaciju. Sistem virtuelne memorije postoji tako da ne morate direktno upravljati fizičkom memorijom. Rukovalac greškama stranice postoji tako da se memorija predaje lenjo i efikasno. Svaki sloj mijenja malu količinu transparentnosti za veliku količinu performansi i pogodnosti.

Programeri koji grade najpouzdanije sisteme s najboljim performansama su oni koji razumiju ove slojeve - ne zato što moraju stalno razmišljati o njima, već zato što kada se dogodi nešto neočekivano (kao što je misteriozna dodjela 72 KB), oni imaju mentalni model da shvate zašto. Bilo da gradite sistem trgovanja u realnom vremenu, mašinu za igre ili poslovnu platformu koja opslužuje hiljade korisnika, sposobnost da rasuđujete o tome šta vaš kod zapravo radi na nivou sistema je ono što odvaja kompetentne programere od izuzetnih. 72 KB nije greška. Vaš alokator radi svoj posao briljantno.