Per què la primera assignació de C++ (m) sempre és de 72 KB?

Els 72 KB que veieu a la vostra primera assignació no són memòria malgastada; és una inversió de rendiment. L'assignador aposta que el vostre programa farà més assignacions aviat, i en pràcticament tots els escenaris del món real, aquesta aposta val molt bé. El cost de l'espai d'adreces virtuals no utilitzat és bàsicament zero als sistemes moderns de 64 bits.

Memòria virtual versus memòria física: per què no importa

Una preocupació comuna entre els desenvolupadors que troben aquest comportament per primera vegada és el malbaratament de recursos. Si només necessito 4 bytes, per què el meu programa consumeix 72 KB? La idea crítica és que la memòria virtual no és memòria física. Quan la glibc amplia l'interrupció del programa en 72 KB, el nucli actualitza els mapes de memòria virtual del procés, però no torna immediatament enrere aquestes pàgines amb RAM física. Les pàgines físiques reals s'assignen sota demanda mitjançant errors de pàgina; només quan el vostre programa escriu a una adreça específica, el nucli li assigna una pàgina real de memòria.

Això vol dir que tot i que la mida virtual del vostre procés augmenta en 72 KB, la seva mida del conjunt resident (RSS), la quantitat de RAM física que es consumeix realment, augmenta només les pàgines que toqueu realment. Per a un sol new int, normalment és una pàgina de 4 KB, més les pàgines que ocupin les metadades de l'arena. L'espai virtual restant es troba allà, llest per al seu ús, i no costa més que espai d'adreces, dels quals teniu 128 TB en un sistema Linux de 64 bits.

Aquesta distinció és fonamental a l'hora de crear perfils i supervisar les aplicacions de producció. Si esteu creant programari que necessita fer un seguiment del consum de recursos reals, ja sigui un backend SaaS, un microservei o un pipeline d'anàlisi com els que s'executen en plataformes com Mewayz per a operacions empresarials, sempre hauríeu de supervisar RSS en lloc de la mida virtual. Eines com /proc/[pid]/smaps, valgrind --tool=massif i pmap us poden oferir petjades precises de la memòria física en lloc d'enganyar les xifres de memòria virtual.

Com els diferents assignadors gestionen la primera assignació

La xifra de 72 KB és específica del ptmalloc2 de glibc. Altres distribuïdors fan diferents compensacions i la sobrecàrrega d'assignació inicial varia en conseqüència. Entendre aquestes diferències és valuós a l'hora de triar un assignador per a aplicacions sensibles al rendiment.

• jemalloc (utilitzat per Facebook, FreeBSD): utilitza una estructura d'arena més granular amb memòria cau local de fils. La sobrecàrrega inicial acostuma a ser més alta (sovint més de 200 KB), però ofereix un millor rendiment multiprocés a causa de la reducció de la contenció de bloqueig.
• tcmalloc (Tread-Caching Malloc de Google): assigna una memòria cau per fil d'aproximadament 2 MB de manera predeterminada, amb una preassignació agressiva. La sobrecàrrega inicial és més alta, però les petites assignacions posteriors són extremadament ràpides.
• malloc de musl libc — Utilitza un disseny molt més senzill basat en mmap per a totes les assignacions. La sobrecàrrega inicial és mínima (sovint només 4 KB per assignació), però el cost per assignació és més elevat a causa de les trucades al sistema més freqüents.
• mimalloc (Microsoft): utilitza l'assignació basada en segments amb segments de 64 MB. La primera assignació activa una reserva virtual de 64 MB (amb un compromís físic mínim), espai d'adreces comercials per a una localitat i un rendiment excepcionals.

L'elecció entre aquests distribuïdors depèn completament de la vostra càrrega de treball. Per a aplicacions de servidor de llarga execució amb una gran assignació de múltiples fils, jemalloc o tcmalloc solen superar el rendiment predeterminat de glibc. Per als sistemes incrustats amb restriccions de memòria, l'enfocament més senzill de musl pot ser preferible malgrat el menor rendiment. Per a la majoria d'aplicacions d'escriptori i de servidor de propòsit general, la sobrecàrrega inicial de 72 KB de ptmalloc2 representa un valor predeterminat raonable que funciona bé sense ajustar.

Ajustar el comportament de l'assignació inicial

Si la sobrecàrrega inicial de 72 KB per defecte és realment problemàtica per al vostre cas d'ús (potser esteu generant milers de processos de curta durada, cadascun fent només un grapat d'assignacions), la glibc proporciona diversos ajustables mitjançant mallopt() i la família de variables d'entorn MALLOC_

El paràmetre M_TOP_PAD controla la quantitat de memòria addicional que sol·licita l'assignador més enllà de la que es necessita immediatament. Establir-lo a 0 amb mallopt(M_TOP_PAD, 0) indica a l'assignador que sol·liciti només el que es necessita, reduint significativament la sobrecàrrega inicial. El paràmetre M_MMAP_THRESHOLD controla la mida per sobre de la qual les assignacions utilitzen mmap en lloc de l'arena. M_TRIM_THRESHOLD controla quan es retorna la memòria alliberada al sistema operatiu. I des de la glibc 2.26, els ajustables glibc.malloc.tcache_count i glibc.malloc.tcache_max us permeten controlar el comportament de la memòria cau del fil.

Tanmateix, una paraula de precaució: ajustar aquests paràmetres sense una anàlisi comparativa acurada gairebé sempre empitjora les coses. Els valors predeterminats es van triar en funció d'un ampli perfil del món real i representen un punt dolç per a la gran majoria de les càrregues de treball. A menys que tingueu proves sòlides del perfil de producció que la sobrecàrrega de malloc és un coll d'ampolla, i hàgiu mesurat l'impacte dels vostres canvis, deixeu els valors predeterminats. L'optimització prematura de l'assignador és una forma particularment insidiosa d'afaitar iac que ha consumit innombrables hores d'enginyeria per obtenir un benefici insignificant.

Què ens ensenya això sobre la programació de sistemes

El misteri de la primera assignació de 72 KB és, en el seu nucli, una lliçó sobre les capes d'abstracció. C++ us dóna la il·lusió que new int assigna 4 bytes. La norma lingüística així ho diu. El teu model mental ho diu. Però entre el vostre codi i el maquinari hi ha una pila de sistemes sofisticats: el temps d'execució C++, l'assignador de biblioteques C, el subsistema de memòria virtual del nucli i la MMU i TLB del maquinari, cadascun afegint els seus propis comportaments, optimitzacions i despeses generals.

Això no és cap defecte. És el punt complet del programari de sistemes. Cada capa existeix per resoldre un problema real: l'assignador existeix perquè no hagis de fer trucades al sistema per a cada assignació. El sistema de memòria virtual existeix, de manera que no cal gestionar directament la memòria física. El gestor d'errors de pàgina existeix, de manera que la memòria es compromet de manera mandrosa i eficient. Cada capa intercanvia una petita quantitat de transparència per una gran quantitat de rendiment i comoditat.

Els desenvolupadors que creen els sistemes més fiables i de rendiment més alt són els que entenen aquestes capes, no perquè hagin de pensar-hi constantment, sinó perquè quan passa alguna cosa inesperada (com ara una misteriosa assignació de 72 KB), tenen el model mental per entendre per què. Tant si esteu construint un sistema de comerç en temps real, un motor de jocs o una plataforma empresarial que serveixi a milers d'usuaris, la capacitat de raonar sobre què fa realment el vostre codi a nivell de sistema és el que separa els desenvolupadors competents dels excepcionals. Els 72 KB no són un error. És el vostre repartidor fent la seva feina de manera brillant.