Dotaz: Serverová aplikace C++ - paměť

[__blr__]

Zdravím,

potřebuji naprogramovat aplikaci v C++ běžící pod Linuxem. V ideálním případě aplikace poběží nonstop, restart aplikace (daemona) nebude žádaný a očekávám, že vždy přinese problémy.

Rád bych se proto zeptal na zkušenosti s různými aplikacemi buď vámi psanými, nebo běžně dostupnými (Apache):

aplikace bude postupem času alokovat relativně malé bloky paměti pro jednotlivé třídy (od několika bajtů po max. desítky kB), některé si ponechá, ale jiné bude alokovat a uvolňovat. Maximální počet jednotlivých tříd bude omezen. Po nějakém měsíci provozu očekávám max. stovky MB, jak využité, tak i alokované a uvolněné.

Má význam zabývat se fragmentací dynamicky alokované paměti (případně jak), nebo jsou v jádru k dispozici nástroje, které si s tím poradí?

Jsou s běžně používanými aplikacemi (daemony) typu Apache problémy v dlouhodobém provozu bez restartu (zpomalení, apod.) ?

Díky

Odpovědi

[debian+]

Isto ziadne restarty? Ani restart pri update "C++ standart library"? Co ak nieco zblne a bude nutny restart?

Nikdy - to sa hovorilo aj o Titaniku.

V cistom C si vies lahlo pamet ukladat RAW na disk a po restarte si nacitat (ak sa nechces nejako transponovat-parsovat).

A co riesis pamet, pamet je lacna. Max par 100MB vies v pohode daj VPS s dobrou cenou. A ako budes casto pristupovat k tej pamete (mame swap aj).

[__blr__]

Nepsal jsem, že restart nebude nikdy. Ale určitě nepředpokládám update každý měsíc/půlrok.

Jde o to, že budu alokovat paměť a zase uvolňovat, ale občas si nějaký blok nechám v paměti. Tudíž nutně vzniknou v paměti fragmenty.

[Jendа]

nebo jsou v jádru k dispozici nástroje, které si s tím poradí?

Co s tím jádro může dělat jiného než případné nepoužívané stránky odswapovat na disk?

[Sten]

Jádro nijak fragmentaci paměti neřeší, to si řeší jednotlivé aplikace samy pomocí alokátorů (v C++ to řeší výchozí operátor new).

Dlouhodobě běžící služby tohle řeší pomocí prefork: hlavní proces pouze udržuje konfiguraci, práci dělají potomci vytvoření přes fork, kteří se po určitém množství práce zabijí. Alternativou je použití vláken a vlastních alokátorů alokujících z anonymního mmap, který se při ukončení vlákna po určitém množství práce uvolní, ale je složité něco takového napsat.

[__blr__]

Aha, díky za info.

V podstatě se též jedná o síťovou aplikaci, taky budu využívat fork, ale potomci musí vydržet po celou běhu programu. Data bych nerad držel u rodiče a přes sdílenou paměť využíval v potomcích kvůli bezpečnosti.

Defacto mi jde o to, jak přesvědčit alokátor, aby "recykloval" alokovanou paměť.

[Jendа]

To víceméně dělá; v C jsou věci jako mallopt a malloc_info, které umožňují tohle ladit, doufám, že alokátory v C++ budou mít něco podobného.

[__blr__]

A jak je to s alokací a recyklací polí (lib. typu) ?

Jinými slovy by mi na to měla odpovědět dokumentace k std::allocator ?

[MadCatX]

C++ žádný vlastní alokátor paměti nemá. std::allocator z libstdc++ alokuje paměť operátorem new, který zavolá Cčkový malloc(). Chování tedy bude záviset na tom, jak je na dané platformě malloc implementován.

Problém, který řešíš bys neměl vyšetřovat teď ale až potom, co napíšeš a obenchmarkuješ nějaký prototyp. Pokud se ukáže, že výchozí systémový alokátor nestačí, překlopíš to na nějaký jiný.

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[__blr__]

Jádro aplikace by mělo běžet kromě PC i na embedded Linuxu s relativně nízkým výkonem CPU (spotřeba) a malou RAM.

V čem se Ti C++ nezdá?

[Sulo]

No ak ti môžem ešte poradiť.

Fragmentáciu pamäte nevyriešiš nejakými nástrojmi. Je to na programátorovi, aby si to vyriešil, bez ohľadu na jazyk.

Práve tým, že budeš alokovať a uvoľnovať a držať nejaké prvky alokované, tak tá fragmentácia nastane alebo nie.

Tak práve pre dlho bežiacu sererovú aplikáciu ( a s maximálnym počtom nejakých prvkov ) by som všetko, čo treba na začiatku programu alokoval a uvoľnil až pri ukončení programu. Presne kvôli fragmentácii pamäti.

Nejaké pole o veľkosti maximalneho počtu prvkov.

[Kojot]

Vzhledem k tomu, že má být maximální počet jednotlivých tříd omezen, tak se dá dopředu alokovat buffery pro jejich maximální počet. Inicializaci pak provádět pomocí placement operatoru new a destrukci přímým voláním destruktoru. Samozřejmě je potřeba si udržovat informaci o volných a inicializovaných pozicích v bufferech pro jednotlivé třídy. Podle mě to ale většinou nemá cenu. Několik démonů běžících 24/7 jsem dělal a neměl jsem zatím problémy s pamětí i s výchozím alokátorem, ale taky to běželo na běžném serveru s dostatkem GB RAM.

[frr]

Proč mám pocit, že je to řádově menší problém, než cokoli server-side s garbage collectorem?