There are many official papers, but each only partially describes the Solaris VMM.
Furthermore, there are many CLI tools whose output is rather difficult to correlate.
Fortunately Solaris 11.1 promises VMM 2.0 at some point which I hope to be better.
At some point Solaris has changed that to: swap = "traditional swap" + "unused RAM".
And by doing this, it turned out that swap somehow became the virtual memory itself.
It's also called virtual swap causing a great deal of confusion and obscurity.
I believe that the "overloaded" meaning of swap word is a big source of confusion.
Options -l and -s of the swap command are complementary to each other.
Both options are crucial to virtual swap (virtual memory) administration.
Consider the previously given swap example on the related status and summary posts.
The same information processed with the -h option may help the eyes:
$ swap -lh; swap -sh
swapfile dev swaplo blocks free
/dev/zvol/dsk/rpool/swap 195,2 4K 8.0G 8.0G
total: 856M allocated + 162M reserved = 1016M used, 12G available
Most of people should normally have other things to do than analyze swap!
Nevertheless, once in a while though it may be relevant to do so.
Facts to consider for memory resource planning include:
- allocated is a concrete value that has already been written by processes. It doesn't include text or static data from the running executables. It corresponds to memory pages either in RAM or disk. If blocks = free then the pages are all in RAM, otherwise some (blocks - free) have reached the disk-based portion of the virutal swap space.
- reserved is an "abstract" value that may need to be honored, eventually.
Keeping free (or the sum of all of them, in case there are many disk-based devices) above reserved is the only way to assure reserved can be honored, without sacrificing any physical memory from the RAM-base virtual swap space or without running out of virtual memory.
- available is normally equal to or bigger than the sum of all blocks.
That's because some unused RAM (physical memory) may be used as swap space as well.
Rationale: On systems with huge amounts of spare RAMs, disk-based virtual swap space can be greatly reduced.
On the given example:
The system has 8 GB of RAM of which, so far, 4 GB is for (virtual) swap.
- Physical memory (prtconf | grep Mem) is a limited and at premium resource. Everybody knows that
overcommit causes swap and, in general, degrades system performance.
Useful figures (in 4 KB units) can be obtained as follows:
$ kstat -p -n system_pages |
egrep 'availrmem|physmem|freemem|locked|pp_kernel'
- ISM is a completely different story. Their pages are "born" on disk.
When such pages get used, they make to physical memory and are locked.
This suggests that other anonymous pages can be switched with ISM pages.
A few safe conclusions are:
- Monitor the desired relationship reserved < free.
Everything that is reserved must be guaranteed to be honored.
- Do provide disk space, otherwise physical memory will be sacrificed.
Furthermore, allocation will be limited to available physical memory only.
Note that disk space alone doesn't help dealing with ISM which locks pages.
Notes:
- The swap concept continues to be a backing store for anonymous (anon) memory pages from the stack, heap, COW and shared segments. Pages of text and static data segments are simply backed by executable files on the ordinary file system (executable files have names, so text and data pages aren't anonymous).
- After shrinking or expanding swap space the above behavior and numbers can "normalize" only after the next reboot. During the transition of a swap space shrink or expansion the behavior and numbers seems to vary in unusual ways.
- It seems difficult to correlate all these values with those from prstat and zonestat perhaps (?) due to rounding or truncation of each tool or maybe just dynamics.
