PostgreSQL: Documentation: 9.4: Managing Kernel Resources(5)

PostgreSQL: Documentation: 9.4: Managing Kernel Resources(5)

时间:2015-06-06 09:49来源:网络整理 作者:KKWL 点击:
Another approach, which can be used with or without alteringvm.overcommit_memory, is to set theprocess-specific oom_score_adj valuefor the postmaster process to -1000,thereby guaranteeing it will not

Another approach, which can be used with or without altering vm.overcommit_memory, is to set the process-specific oom_score_adj value for the postmaster process to -1000, thereby guaranteeing it will not be targeted by the OOM killer. The simplest way to do this is to execute

echo -1000 > /proc/self/oom_score_adj

in the postmaster's startup script just before invoking the postmaster. Note that this action must be done as root, or it will have no effect; so a root-owned startup script is the easiest place to do it. If you do this, you may also wish to build PostgreSQL with -DLINUX_OOM_SCORE_ADJ=0 added to CPPFLAGS. That will cause postmaster child processes to run with the normal oom_score_adj value of zero, so that the OOM killer can still target them at need.

Older Linux kernels do not offer /proc/self/oom_score_adj, but may have a previous version of the same functionality called /proc/self/oom_adj. This works the same except the disable value is -17 not -1000. The corresponding build flag for PostgreSQL is -DLINUX_OOM_ADJ=0.

Note: Some vendors' Linux 2.4 kernels are reported to have early versions of the 2.6 overcommit sysctl parameter. However, setting vm.overcommit_memory to 2 on a 2.4 kernel that does not have the relevant code will make things worse, not better. It is recommended that you inspect the actual kernel source code (see the function vm_enough_memory in the file mm/mmap.c) to verify what is supported in your kernel before you try this in a 2.4 installation. The presence of the overcommit-accounting documentation file should not be taken as evidence that the feature is there. If in any doubt, consult a kernel expert or your kernel vendor.

17.4.4. Linux huge pages

Using huge pages reduces overhead when using large contiguous chunks of memory, like PostgreSQL does. To enable this feature in PostgreSQL you need a kernel with CONFIG_HUGETLBFS=y and CONFIG_HUGETLB_PAGE=y. You also have to tune the system setting vm.nr_hugepages. To estimate the number of necessary huge pages start PostgreSQL without huge pages enabled and check the VmPeak value from the proc file system:

$ head -1 /path/to/data/directory/ 4170 $ grep ^VmPeak /proc/4170/status VmPeak: 6490428 kB

6490428 / 2048 (PAGE_SIZE is 2MB in this case) are roughly 3169.154 huge pages, so you will need at least 3170 huge pages:

$ sysctl -w vm.nr_hugepages=3170

Sometimes the kernel is not able to allocate the desired number of huge pages, so it might be necessary to repeat that command or to reboot. Don't forget to add an entry to /etc/sysctl.conf to persist this setting through reboots.

The default behavior for huge pages in PostgreSQL is to use them when possible and to fallback to normal pages when failing. To enforce the use of huge pages, you can set huge_pages to on. Note that in this case PostgreSQL will fail to start if not enough huge pages are available.

For a detailed description of the Linux huge pages feature have a look at