Influence of the swappiness sysctl on the SLES9 Memory management

This document (3469718) is provided subject to the disclaimer at the end of this document.


Novell SUSE Linux Enterprise Server 9

You have a system with a large amount of memory (more than 16 Gb).
There are some memory demanding applications running but you have calculated that your system should be large enough to cope with that.


You observe situations in which the machine reacts extremely
slow. It seems that these situations are triggered by high i/o
Checking your available memory you observe that most of the RAM ist
taken by the file system cache.
You try to get your applications more free ram by lowering the kernel sysctl:


This makes the behaviour even worse.


The kernel was not well tuned for situations with a high imbalance between active and inactive memory pages.
A fix has been introduced with kernel:
In order to use the fix, please install this kernel version or above and modify the swappiness via e.g.:

echo "30"> /proc/sys/vm/swappiness

Please do not put swappiness to zero since this will block some other important optimizations.

In order to set the value permanently you can edit the file:


and enter the following:

vm.swappiness = 30

Additional Information

Some technical details:

The freeable pages in the Linux VM are queued in two lru lists: active and
inactive. For a mapped page to be swapped/paged out it must be deactivated
first (deactivated means the page must be moved from the active to the inactive

The code that moves mapped pages from active list to inactive list may be
disabled using certain logic which uses a tunable parameter called
"swappiness". This is meant to control when exactly the code should be
The logic used has a failsafe mechanism which will guarantee the kernel is able
to make progress by swapping / paging out mapped pages. This will happen even
if the other parts of the logic would forbid it.
The failsafe used is the "distress" variable. Before the failsafe can kick in,
the VM will perform a lot of work, resulting in a large number of CPU cycles
being wasted without making progress.
Normally with the default swappiness value, we deactivate mapped pages
regardless of the distress value, so no real cpu cycles are wasted. The CPU
waste becomes visible if swappiness is set to low values (below 40).

Kurt Garloff developed a patch that extends the failsafe mechanism to not only
depend on the distress but to start deactivating the mapped pages when there is
huge imbalance between active and inactive list. This should alleviate the
dependency on the distress value, and it should provide for a more graceful
behavior with low swappiness values, while still retaining similar swappiness


This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:3469718
  • Creation Date: 27-Mar-2008
  • Modified Date:03-Mar-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact:

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center