zswap – compcache, compressed swap for better performance

First, here is a link to article on compcache.

http://code.google.com/p/compcache/wiki/CompilingAndUsingNew

zswap is already in the kernel and you can see the documentation in the kernel documentation. Here is the name of the file if you need:

/usr/share/doc/kernel-doc-$(uname -r)/Documentation/vm/zswap.txt

Here is the overview, in case you do not want to install kernel-doc

Overview:

Zswap is a lightweight compressed cache for swap pages. It takes pages that are
in the process of being swapped out and attempts to compress them into a
dynamically allocated RAM-based memory pool.  zswap basically trades CPU cycles
for potentially reduced swap I/O.  This trade-off can also result in a
significant performance improvement if reads from the compressed cache are
faster than reads from a swap device.

NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
reclaim.  This interaction has not be fully explored on the large set of
potential configurations and workloads that exist.  For this reason, zswap
is a work in progress and should be considered experimental.

Some potential benefits:
* Desktop/laptop users with limited RAM capacities can mitigate the
    performance impact of swapping.
* Overcommitted guests that share a common I/O resource can
    dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
    throttling by the hypervisor. This allows more work to get done with less
    impact to the guest workload and guests sharing the I/O subsystem
* Users with SSDs as swap devices can extend the life of the device by
    drastically reducing life-shortening writes.

Zswap evicts pages from compressed cache on an LRU basis to the backing swap
device when the compressed pool reaches it size limit.  This requirement had
been identified in prior community discussions.

To enabled zswap, the “enabled” attribute must be set to 1 at boot time.  e.g.
zswap.enabled=1

 

Enhanced by Zemanta

vmstat – what it is and how to use?

Paging on 386 - address translation (polish texts)
Image via Wikipedia

vmstat provides a summary of various functions within the system, including system wide free memory, paging counters, summarized disk activity, system calls and cpu utilization.

The output of vmstat and description of what each field means:

The first line of output from vmstat shows a summary since boot,
followed by the output over the last 3 seconds for each additional line.

The vmstat command reports the amount of swap space that is free (not reserved or allocated). This is the most useful measure.
Swap space is reserved first, then may be allocated. When a process requests memory via malloc() for example, the address space is created, but real pages are not allocated to it. At this point, swap space is reserved, but not allocated. The first time each page is accessed, a real page of memory is allocated to it and swap space is also allocated.

The vmstat paging counters provide us with some insight as to how busy VM system is, and if there are any memory resource issues.
The first thing to look for in the paging counters is the scan rate. The scan rate is the number of pages per second that the pageout scanner is scanning. If the scan rate is consistently zero, then the pageout scanner is not running, and there must be greater than lotsfree free memory. If the scan rate is zero, then there is no memory shortage. A non-zero scan rate does not always mean there is cause for concern. Remember that as reads and writes occur, pages are taken from the free list and eventually the amount of free memory will fall below lotsfree. In this case, the pageout scanner will be invoked to free up memory, hence a non-zero scan rate.

 

 

Enhanced by Zemanta