Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] memory management



On 6/21/2015 2:23 PM, Tom Metro wrote:
> That doesn't entirely make sense. If setting swappiness to zero means
> swap is never used, and setting it to a high value means it is
> aggressively used, then in the latter case it means the kernel is moving
> stuff from RAM to swap. If it is moved to swap, it ought to free up
> physical RAM.

swappiness does not prevent the kernel from swapping. It controls how 
aggressive the kernel is in writing out least-used pages to disk or 
other non-volatile storage.

When set to 0 the kernel will not write pages to disk until all physical 
RAM is allocated. Then it will start writing out pages normally. The 
higher the setting, the more aggressive the kernel will be in writing 
out least-used pages.

Clean pages (allocated pages that have been written to disk) remain in 
the page cache in case they are needed. swappiness = 100 does not mean 
that every page gets read from disk every time it is accessed. Pages are 
dropped from the page cache when their processes release the allocations 
or processes try to allocate more RAM. The kernel drops least-used clean 
pages from the page cache to meet the allocation request. swappiness has 
no effect on the page cache.

When a process tries to allocate more pages than the total of clean and 
unallocated pages in the page cache, well, that's an overload. 
Overloaded system is overloaded. Game over. Install more RAM or don't 
overload the system. If neither option is viable then put your page file 
or partition on a fast SSD. That won't solve the problem but it will 
make it seem less severe.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org