Wiki

User Tools

Site Tools

Trace:
ubuntu:memory:disable_the_oom_killer

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
ubuntu:memory:disable_the_oom_killer [2019/11/30 14:09] – created peterubuntu:memory:disable_the_oom_killer [2020/07/15 09:30] (current) – external edit 127.0.0.1
Line 93: Line 93:
 </code> </code>
  
-Result:+result:
  
-<code>+<code bash>
 VmPeak:  3141876 kB VmPeak:  3141876 kB
 VmSize:  3141876 kB VmSize:  3141876 kB
Line 114: Line 114:
 </code> </code>
  
-Result:+result:
  
-<code>+<code bash>
 VmPeak:  1072512 kB VmPeak:  1072512 kB
 VmSize:  1072512 kB VmSize:  1072512 kB
Line 153: Line 153:
 </code> </code>
  
-Result:+result:
  
-<code>+<code bash>
 0039d000-003b2000 r-xp 00000000 16:41 1080084    /lib/ld-2.3.3.so 0039d000-003b2000 r-xp 00000000 16:41 1080084    /lib/ld-2.3.3.so
 003b2000-003b3000 r-xp 00014000 16:41 1080084    /lib/ld-2.3.3.so 003b2000-003b3000 r-xp 00014000 16:41 1080084    /lib/ld-2.3.3.so
Line 178: Line 178:
 How does the map for program A look when it can't allocate more memory blocks?  With a trivial change to pause the program (see loop.c and loop-calloc.c) just before it exits, the final map is: How does the map for program A look when it can't allocate more memory blocks?  With a trivial change to pause the program (see loop.c and loop-calloc.c) just before it exits, the final map is:
  
-<code>+<code bash>
 0009a000-0039d000 rwxp 0009a000 00:00 0 ---------> (allocated block) 0009a000-0039d000 rwxp 0009a000 00:00 0 ---------> (allocated block)
 0039d000-003b2000 r-xp 00000000 16:41 1080084    /lib/ld-2.3.3.so 0039d000-003b2000 r-xp 00000000 16:41 1080084    /lib/ld-2.3.3.so
Line 210: Line 210:
 </code> </code>
  
-Result:+result:
  
-<code>+<code bash>
 36:Memory: 255716k/262080k available (2083k kernel code, 5772k reserved, 36:Memory: 255716k/262080k available (2083k kernel code, 5772k reserved,
     637k data, 172k init, 0k highmem)     637k data, 172k init, 0k highmem)
Line 240: Line 240:
 This is where the understanding of swap as RAM extension comes from.  Clearly, accessing the page requires bringing it back into RAM. This is where the understanding of swap as RAM extension comes from.  Clearly, accessing the page requires bringing it back into RAM.
  
 +----
  
 ===== Inside the Allocator ===== ===== Inside the Allocator =====
Line 262: Line 262:
  
 This implies that a free chunk may go abandoned if the allocator cannot fit future requests within it.  Failure to coalesce free chunks may also trigger faster OOM.  This is usually an indication of moderate to bad memory fragmentation. This implies that a free chunk may go abandoned if the allocator cannot fit future requests within it.  Failure to coalesce free chunks may also trigger faster OOM.  This is usually an indication of moderate to bad memory fragmentation.
 +
 +----
  
 ===== Recovery ===== ===== Recovery =====
Line 285: Line 287:
 The kernel uses the SIGTERM signal to inform the target process that it should stop. The kernel uses the SIGTERM signal to inform the target process that it should stop.
  
 +----
  
 ===== How to Reduce OOM Risk ===== ===== How to Reduce OOM Risk =====
Line 296: Line 299:
 For example, instead of doing: For example, instead of doing:
  
-<code>+<code c>
         void *a;         void *a;
         void *b;         void *b;
Line 313: Line 316:
 It's better to do: It's better to do:
  
-<code>+<code c>
         a = malloc(1024);         a = malloc(1024);
         c = malloc(4096);         c = malloc(4096);
Line 329: Line 332:
 You can do further experiments by passing various numbers as the program parameter.  This parameter acts as the request size of the malloc() call. You can do further experiments by passing various numbers as the program parameter.  This parameter acts as the request size of the malloc() call.
  
 +----
  
 ===== Tweak Kernel's Overcommit Behavior ===== ===== Tweak Kernel's Overcommit Behavior =====
Line 341: Line 345:
  
 Suppose that you have 256MB of RAM and 256MB of swap and you want to limit overcommit at 384MB.  That means 256 + 50 percent * 256MB, so put 50 on /proc/sys/vm/overcommit_ratio. Suppose that you have 256MB of RAM and 256MB of swap and you want to limit overcommit at 384MB.  That means 256 + 50 percent * 256MB, so put 50 on /proc/sys/vm/overcommit_ratio.
 +
 +----
  
 ==== Check for NULL Pointer after Memory Allocation and Audit for Memory Leak ==== ==== Check for NULL Pointer after Memory Allocation and Audit for Memory Leak ====
Line 347: Line 353:
  
 Memory leak is also a source of unnecessary memory consumption. A leaked memory block is one that the application no longer tracks, but that the kernel will not reclaim because, from the kernel's point of view, the task still has it under control. Valgrind is a nice tool to find out such occurrences inside your code without the need to re-code. Memory leak is also a source of unnecessary memory consumption. A leaked memory block is one that the application no longer tracks, but that the kernel will not reclaim because, from the kernel's point of view, the task still has it under control. Valgrind is a nice tool to find out such occurrences inside your code without the need to re-code.
 +
 +----
  
 ==== Always Consult Memory Allocation Statistics ==== ==== Always Consult Memory Allocation Statistics ====
Line 374: Line 382:
  
 That means to get precise information, you must programmatically parse the /proc/meminfo and calculate it by yourself. If you're lazy, take the procps source package as a reference on how to do it. This package contains tools such as ps, top, and free. It is available under the GPL. That means to get precise information, you must programmatically parse the /proc/meminfo and calculate it by yourself. If you're lazy, take the procps source package as a reference on how to do it. This package contains tools such as ps, top, and free. It is available under the GPL.
 +
 +----
  
 ==== Experiments with Alternative Memory Allocators ==== ==== Experiments with Alternative Memory Allocators ====
  
 Different allocators yield different ways to manage memory chunks and to shrink, expand, and create virtual memory areas. Hoard is one example. Emery Berger from the University of Massachusetts wrote it as a high performance memory allocator. Hoard seems to work best for multi-threaded applications; it introduces the concept of per-CPU heap. Different allocators yield different ways to manage memory chunks and to shrink, expand, and create virtual memory areas. Hoard is one example. Emery Berger from the University of Massachusetts wrote it as a high performance memory allocator. Hoard seems to work best for multi-threaded applications; it introduces the concept of per-CPU heap.
 +
 +----
  
 ==== Use 64-bit Platforms ==== ==== Use 64-bit Platforms ====
Line 384: Line 396:
  
 This has no connection to extended addressing schemes, such as Intel's Physical Address Extension (PAE), which allows a 32-bit Intel processor to address up to 64GB of RAM.  This addressing deals with physical address, while in the virtual address context, the user space itself is still 3GB (assuming the 3:1 VM split).  This extra memory is reachable, but not all mappable into the address space.  Unmappable portions of RAM are unusable. This has no connection to extended addressing schemes, such as Intel's Physical Address Extension (PAE), which allows a 32-bit Intel processor to address up to 64GB of RAM.  This addressing deals with physical address, while in the virtual address context, the user space itself is still 3GB (assuming the 3:1 VM split).  This extra memory is reachable, but not all mappable into the address space.  Unmappable portions of RAM are unusable.
 +
 +----
  
 ==== Consider Packed Types on Structures ==== ==== Consider Packed Types on Structures ====
ubuntu/memory/disable_the_oom_killer.1575122981.txt.gz · Last modified: 2020/07/15 09:30 (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki