Jak mohu alokovat paměť v Linuxu bez přetížení
To je nabitá otázka, nebo přinejmenším nesprávná. Otázka je založena na nesprávném předpokladu, takže odpověď na uvedenou otázku je v nejlepším případě irelevantní a v horším případě zavádějící.
Přetížení paměti je celosystémová politika – protože určuje, kolik virtuální paměti je zpřístupněno procesům – a není to něco, co by si proces mohl rozhodnout sám.
Je na správci systému, aby určil, zda je paměť přetížená nebo ne. V Linuxu je tato politika docela laditelná (viz např. /proc/sys/vm/overcommit_memory u člověka 5 proc. Během přidělování nemůže proces udělat nic, co by ovlivnilo zásadu nadměrného potvrzení paměti .
OP také vypadá, že má zájem na tom, aby jejich procesy byly imunní vůči zabijákovi nedostatku paměti (OOM killer) v Linuxu. (OOM killer v Linuxu je technika používaná ke zmírnění tlaku na paměť tím, že zabije procesy, a tak uvolní jejich zdroje zpět do systému.)
I to je nesprávný přístup, protože OOM killer je heuristický proces, jehož účelem není „potrestat nebo zabít špatně se chovající procesy“, ale udržet systém v provozu. Tato funkce je také docela laditelná v Linuxu a správce systému může dokonce vyladit pravděpodobnost, že každý proces bude zabit v situacích vysokého tlaku paměti. Kromě množství paměti použité procesem není na procesu, aby ovlivnil, zda jej zabiják OOM zabije v situacích s nedostatkem paměti; je to také otázka zásad spravovaná správcem systému, nikoli samotné procesy.
Předpokládal jsem, že skutečná otázka, kterou se OP snaží vyřešit, je, jak psát linuxové aplikace nebo služby, které mohou dynamicky reagovat na tlak paměti, jinak než jen umíráním (kvůli SIGSEGV nebo zabijákovi OOM). Odpověď je není -- místo toho necháte správce systému, aby se staral o to, co je pro něj důležité, v pracovní zátěži, kterou má --, pokud vaše aplikace nebo služba nevyužívá mnoho a mnoho paměti, a proto je pravděpodobné, že dojde k neoprávněnému zabití při vysoké paměti tlak. (Zejména pokud je datová sada dostatečně velká na to, aby vyžadovala povolení mnohem většího množství swapu, než by bylo jinak povoleno, což způsobuje vyšší riziko swapové bouře a pozdního, ale příliš silného zabijáka OOM.)
Řešením, nebo alespoň přístupem, který funguje, je zamknout kritické části paměti (nebo dokonce celou aplikaci/službu, pokud pracuje na citlivých datech, která by neměla být swapována na disk), nebo použít paměťovou mapu s vyhrazený podpůrný soubor. (Pro posledně jmenované je zde příklad, který jsem napsal v roce 2011 a který manipuluje s datovou sadou o velikosti terabajtu.)
Zabiják OOM může proces stále zabít a SIGSEGV se stále vyskytuje (kvůli interní alokaci funkcí knihovny, které jádro nedokáže poskytnout zálohu RAM), pokud není celá aplikace uzamčena na RAM, ale alespoň služba/proces již není nespravedlivý cílené, jen proto, že využívá spoustu paměti.
Je možné zachytit signál SIGSEGV (k tomu dochází, když není k dispozici žádná paměť pro zálohování virtuální paměti), ale zatím jsem neviděl případ použití, který by zaručoval složitost kódu a požadované úsilí na údržbu.
Stručně řečeno, správná odpověď na uvedenou otázku je ne, nedělejte to .