|
This document gives you details about tunable virtual memory parameters in Linux, that can help you to improve your system performance. vm.nr_hugepages
Linux 2.6 has the feature which allows processes to use large paging sizes, called as hugetlb pages. This feature will be used to gain good performance in high performance computing systems. Hugetlb behavior is similar to that of bigpages, the pages are backed by large TLB entries, are not pageable, and are preallocated, which means that once you allocate X megabytes of hugetlb pages, that amount of physical memory can be used only through hugetlbfs.
/proc/meminfo also provides information about the total number of hugetlb pages configured in the kernel. It also displays information about the number of free hugetlb pages at any time. It also displays information about the configured hugepage size - this is needed for generating the proper alignment and size of the arguments to the above system calls.
Contents of /proc/meminfo HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
here
HugePages_Total is the size of the pool of hugepages.
HugePages_Free is the number of hugepages in the pool that are not yet allocated.
HugePages_Rsvd is for "reserved," and is the number of hugepages for which a commitment to allocate from the pool has been made, but no allocation has yet been made.
HugePages_Surp is for "surplus," and is the number of hugepages in the pool. The maximum number of surplus hugepages is controlled by /proc/sys/vm/nr_overcommit_hugepages.
The file /proc/sys/vm/nr_hugepages (vm.nr_hugepages) indicates the current number of configured hugetlb pages in the kernel. Root user can dynamically request more (or free some pre-configured) hugepages. The allocation (or deallocation) of hugetlb pages is possible only if there are enough physically contiguous free pages in system.
Use the following command to dynamically allocate/deallocate hugepages. You can also use sysctl command to change this value.
echo 10 > /proc/sys/vm/nr_hugepages
vm.overcommit_memory & vm.overcommit_ratio
If you are running high memory intensive application that requires more memory per process, you can tune vm.overcommit_memory. This kernel parameter controls overcommit of system memory, possibly allowing processes to allocate more memory than is actually available. Enabling overcommit_memory can create significant performance gains at little cost but only if your applications are suited to its use. If your applications use all of the memory they allocate, memory overcommit can lead to short performance gains followed by long latencies as your applications are swapped out to disk frequently when they must compete for oversubscribed RAM.
There are three modes of overcommit_memory.
- 0 - Heuristic overcommit handling. The overcommits of address space are refused in this mode. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. This is the default.
- 1 - Always overcommit. The kernel performs no memory over commit handling. Under this setting, the potential for memory overload is increased, but so is performance for memory intensive tasks. Appropriate for some scientific applications.
- 2 - Don't overcommit. The kernel fails requests for memory that add up to all of swap plus the percent of physical RAM specified in /proc/sys/vm/overcommit_ratio. This setting is good for the systems which requires less risk of memory overcommitment.
overcommit_ratio — The overcommit_ratio tunable parameter defines the amount by which the kernel overextends its memory resources in the event that overcommit_memory is set to the value of 2. The value in this file represents a percentage added to the amount of actual RAM in a system when considering whether to grant a particular memory request. The general formula for this tunable is: allocatable memory=(swap size + (RAM size * overcommit ratio))
Note : Tuning kernel parameters always requires extensive study as it can create either performance gains or the otherway.
|
