Pages

How to find a process using the ipcs shared memory segment


Process id can be identified using lsof

# lsof | egrep "shmid"

# ipcs -m
------ Shared Memory Segments --------
key               shmid      owner      perms      bytes      nattch     status      
0x0052e2c1 4194319    postgres  600        11083776   2 

From the above output you gets the shmid

# lsof | egrep "4194319"
postmaste 15289  postgres  DEL       REG              0,9               4194319 /SYSV0052e2c1
postmaste 15293  postgres  DEL       REG              0,9               4194319 /SYSV0052e2c1


And as shown above, 15289 and 15293 are the process IDs.

What is transparent hugepages


Transparent Huge Pages (THP) are enabled by default in RHEL 6 for all applications. The kernel attempts to allocate hugepages whenever possible and any Linux process will receive 2MB pages if the mmap region is 2MB naturally aligned. The main kernel address space itself is mapped with hugepages, reducing TLB pressure from kernel code. For general information on Hugepages, see: What are Huge Pages ?

The kernel will always attempt to satisfy a memory allocation using hugepages. If no hugepages are available (due to non availability of physically continuous memory for example) the kernel will fall back to the regular 4KB pages. THP are also swappable (unlike hugetlbfs). This is achieved by breaking the huge page to smaller 4KB pages, which are then swapped out normally.

But to use hugepages effectively, the kernel must find physically continuous areas of memory big enough to satisfy the request, and also properly aligned. For this, a khugepaged kernel thread has been added. This thread will occasionally attempt to substitute smaller pages being used currently with a hugepage allocation, thus maximizing THP usage.

Also, THP is only enabled for anonymous memory regions. There are plans to add support for tmpfs and page cache. THP tunables are found in the /sys tree under /sys/kernel/mm/redhat_transparent_hugepage.

The values for /sys/kernel/mm/redhat_transparent_hugepage/enabled can be one of the following:

always   - always use THP
never    -  disable THP

khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". The redhat_transparent_hugepage/defrag parameter takes the same values and it controls whether the kernel should make aggressive use of memory compaction to make more hugepages available.

To Check system-wide THP usage

Run the following command to check system-wide THP usage:

# grep AnonHugePages /proc/meminfo 
AnonHugePages:    632832 kB
Note: Red Hat Enterprise Linux 6.2 or later publishes additional THP monitoring via /proc/vmstat

# egrep 'trans|thp' /proc/vmstat
nr_anon_transparent_hugepages 2018
thp_fault_alloc 7302
thp_fault_fallback 0
thp_collapse_alloc 401
thp_collapse_alloc_failed 0
thp_split 21
To Check THP usage per process

# grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '
/proc/7519/smaps:AnonHugePages:    305152 kB
UID        PID  PPID  C STIME TTY          TIME CMD
qemu      7519     1  1 08:53 ?        00:00:48 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name rhel7 -S -machine pc-i440fx-1.6,accel=kvm,usb=of
/proc/7610/smaps:AnonHugePages:    491520 kB
UID        PID  PPID  C STIME TTY          TIME CMD
qemu      7610     1  2 08:53 ?        00:01:30 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name util6vm -S -machine pc-i440fx-1.6,accel=kvm,usb=
/proc/7788/smaps:AnonHugePages:    389120 kB
UID        PID  PPID  C STIME TTY          TIME CMD
qemu      7788     1  1 08:54 ?        00:00:55 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name rhel64eus -S -machine pc-i440fx-1.6,accel=kvm,us
To disable THP at run time

Append the following to the kernel command line in grub.conf
transparent_hugepage=never
Run the following commands to disable THP on-the-fly:

# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

NOTE:Running the above commands will stop only creation and usage of the new THP. The THP which were created and used at the moment the above commands were run would not be disassembled into the regular memory pages. To get rid of THP completely the system should be rebooted with THP disabled at boot time.

How to tell if Explicit HugePages is enabled or disabled

There can be two types of HugePages in the system: Explicit Huge Pages which are allocated explicitly by vm.nr_hugepages sysctl parameter and Tranparent Huge Pages which are allocated automatically by the kernel. See below on how to tell if Explicit HugePages is enabled or disabled.

Explicit HugePages DISABLED

If the value of HugePages_Total is "0" it means HugePages is disabled on the system.

# grep -i HugePages_Total /proc/meminfo 
HugePages_Total:       0
Similarly, if the value in /proc/sys/vm/nr_hugepages file or vm.nr_hugepages sysctl parameter is "0" it means HugePages is disabled on the system:

# cat /proc/sys/vm/nr_hugepages 
0
# sysctl vm.nr_hugepages
vm.nr_hugepages = 0
Explicit HugePages ENABLED

If the value of HugePages_Total is greater than "0", it means HugePages is enabled on the system

# grep -i HugePages_Total /proc/meminfo 
HugePages_Total:       1024
Similarly if the value in /proc/sys/vm/nr_hugepages file or vm.nr_hugepages sysctl parameter is greater than "0", it means HugePages is enabled on the system:

# cat /proc/sys/vm/nr_hugepages 
1024
# sysctl vm.nr_hugepages
vm.nr_hugepages = 1024


What are Huge Pages

  • Hugepages is a feature that allows the Linux kernel to utilize the multiple page size capabilities of modern hardware architectures. Linux creates multiple pages of virtual memory, mapped from both physical RAM and swap. A page is the basic unit of virtual memory, with the default page size being 4096 Bytes in the x86 architecture.

  • Linux uses a mechanism in the CPU architecture called "Translation Lookaside Buffers" (TLB) to manage the mapping of virtual memory pages to actual physical memory addresses. The TLB is a limited hardware resource, so utilizing a huge amount of physical memory with the default page size consumes the TLB and adds processing overhead - many pages of size 4096 Bytes equates to many TLB resources consumed. By utilizing Huge Pages, we are able to create pages of much larger sizes, each page consuming a single resource in the TLB. A side effect of creating Huge Pages is that the physical memory that is mapped to a Huge Page is no longer subject to normal memory allocations or managed by the kernel virtual memory manager, so Huge Pages are essentially 'protected' and are available only to applications that request them. Huge Pages are 'pinned' to physical RAM and cannot be swapped/paged out.

  • A typical purpose for allocating Huge Pages is for an application that has characteristic high memory use, and you wish to ensure that the pages it uses are never swapped out when the system is under memory pressure. Another purpose is to manage memory usage on a 32bit system - Creating Huge Pages and configuring applications to use them will reduce the kernel's memory management overhead since it will be managing fewer pages. The kernel virtual memory manager utilizes low memory - fewer pages to manage means it will consume less low memory.

  • In the Linux 2.6 series of kernels, hugepages is enabled using the CONFIG_HUGETLB_PAGE feature when the kernel is built. All kernels supplied by Red Hat for the Red Hat Enterprise Linux 4 release and later releases have the feature enabled.

  • Systems with large amount of memory can be configured to utilize the memory more efficiently by setting aside a portion dedicated for hugepages. The actual size of the page is dependent on the system architecture. A typical x86 system will have a Huge Page Size of 2048 kBytes. The huge page size may be found by looking at /proc/meminfo

# cat /proc/meminfo |grep Hugepagesize
Hugepagesize: 2048 kB
  • In RHEL 6 or later, the hugepagesize can be displayed using the following command (this value is in bytes):

# hugeadm --page-sizes-all
2097152

Note: Enabling hugepages requires the kernel to find contiguous, aligned unallocated regions of memory. For most systems, this means that a reboot will be required to allocate the hugepages.

How to limit memory usage per user in Linux


It is possible to limit the amount of memory that each process can allocate with the RLIMIT facility in Red Hat Enterprise Linux. RLIMIT_AS limits the size of the virtual address space and it is a suitable solution in many cases which require limiting per-process memory consumption even though there are many limits related to memory.


# vi /etc/security/limits.conf
.... 
daniel hard as 1048576  
.... 

# ulimit -v
1048576

In the example above, processes running as 'daniel' user can only use 1GB virtual address space. So, each application used by daniel cannot allocate more than 1 GB memory space.

Note : this limitation does not affect an amount of physical memory directly, and the values are in KiB (1024-byte).

hugepages support in a XEN virtual guest


  • hugepages cannot be used in a paravirtualized XEN guest. RHEL 5 doesn't have this feature enabled. If vm.nr_hugepages is set in RHEL 6 the pages can be allocated, but as soon as they are used the paravirtualized guest will crash.

  • hugepages can be used in a fully virtualized (HVM) XEN guest as well as in a KVM environment.
On an fully virtualized guest, it will report the BIOS vendor as "xen" and the System product name will be "HVM domU".

[root@test2 ~]# dmidecode
# dmidecode 2.12
SMBIOS 2.4 present.
10 structures occupying 347 bytes.
Table at 0x000E901F.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
    Vendor: Xen
    Version: 3.1.2-371.4.1.el5
    Release Date: 05/07/2013
    Address: 0xE8000
    Runtime Size: 96 kB
    ROM Size: 64 kB
    Characteristics:
        Targeted content distribution is supported
    BIOS Revision: 3.1

Handle 0x0100, DMI type 1, 27 bytes
System Information
    Manufacturer: Red Hat
    Product Name: HVM domU
    Version: 3.1.2-371.4.1.el5
    Serial Number: 4c63d1ea-8876-89a3-d0e7-342fe676a41f
    UUID: 4C63D1EA-8876-89A3-D0E7-342FE676A41F
    Wake-up Type: Power Switch
    SKU Number: Not Specified
    Family: Red Hat Enterprise Linux


On a paravirtualized guest, dmidecode will be empty

[root@test ~]# dmidecode
# dmidecode 2.11
# No SMBIOS nor DMI entry point found, sorry.