Řešení 1:
Doporučil bych povolit normální linuxovou výměnu paměti ve věcech, které se skutečně používají, tak jak se používají.
Jediné, co mě napadá, je vypnout swap a znovu ho zapnout
sudo swapoff -a
sudo swapon -a
To předpokládá, že máte dostatek volné fyzické paměti pro uložení všeho ve swapu...
Řešení 2:
Můžete jej naladit ozvěnou nějakého čísla mezi 0 až 100 do /proc/sys/vm/swappiness .
Tento ovládací prvek se používá k definování toho, jak agresivní bude jádro odkládat stránky paměti. Vyšší hodnoty zvýší agresivitu, nižší hodnoty sníží množství swapu . Hodnota 0 dává jádru pokyn, aby nezahajovalo swap, dokud množství volných a souborem zálohovaných stránek nebude menší než horní hranice v zóně.
Výchozí hodnota je 60.
Řešení 3:
Linux odvádí dobrou práci se správou paměti a neměli byste mu stát v cestě. Nastavení vm.swappiness (zmíněné dříve) mu nebrání. Je pravděpodobnější, že se setkáte s podivnými problémy, když budete dělat věci jiným způsobem.
Co jste spustili, že to tak hladoví po paměti? Dá se to naladit? Pokud nemá vlastní direktivy pro omezení paměti, můžete se také podívat na ulimit.
Řešení 4:
Pokud máte k dispozici paměť pro všechny vaše aplikace, je v pořádku nastavit swappiness na 0, aby se věci nevyměnily. Například qemu-kvm je velkým cílem pro výměnu VMM, protože se „zdá“, že je většinu času nečinný. Viděl jsem, že až 80 % paměti qemu-kvm bylo zapsáno k odložení. Virtuální počítače běžící v qemu-kvm téměř přestanou reagovat, protože jim dochází swap (ačkoli host netuší, že se to děje). Hostující VM si bude myslet, že to funguje nanejvýš excelentně, i když se to ve skutečnosti strašně vleče. Když se hromada virtuálních počítačů „probudí“ a začnu dělat věci, může to vyšplhat průměrnou zátěž až na 30, a to i na hardwaru podnikové třídy s dostatkem rychlé paměti a disku. Domnívám se, že se jedná o selhání předdefinovaného návrhu qemu-kvm.
Doufám, že to někomu pomůže.