Find the answer to your Linux question:
Results 1 to 3 of 3
* RHEL4 2.6.9-22 (x86_64) * gcc- 3.4.4 Physical Memory: 16 GB We have a bunch of applications processes (written C++ and Java) that work cooperatively using a messaging framework. In ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Feb 2008
    Posts
    3

    Memory issue...


    * RHEL4 2.6.9-22 (x86_64)
    * gcc- 3.4.4

    Physical Memory: 16 GB

    We have a bunch of applications processes (written C++ and Java) that work cooperatively using a messaging framework.

    In the C++ applications there is frequent dynamic allocation and freeing of heap.

    Recently we had couple of instances of OOM-Killer bring down one of our application.

    I started out suspecting the memory leaks and wanted to use Valgrind but it made the application to slow so I profiled using CCMalloc. Using that report and tracing the code gave little input because there are calls to some shared Library modules that I am not sure of what is happeing.

    But the point of concern for me was the comment made by the library package vendor and is as follows,

    "The increase in the size of application memory could be caused because of fragmented memory"

    As I understand in fragmented memory situation the allocator would not give me a new allocation request larger than the max block size available. What I don't understand is how is this fragmented memory accounted for the increase in my application size??

    Could anybody throw some light on the relationship of the fragmented memory to the increase in size of my application?

  2. #2
    Linux Guru
    Join Date
    Nov 2007
    Posts
    1,746
    I am not a kernel memory management expert, but as always Google can find tons of info.

    When Linux runs out of memory...

    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.
    The way I read that, your application didn't necessarily use all of the memory in the system. If these smaller free chunks of memory are not "defrag'ed" into larger chunks, then they may never get re-used for furture allocations - leading to an OOM condition.

    There are many discussions about memory fragmentation and analyzing memory allocation while your code is running in order to optimize memory management in your app.

    And there are discussions about kernel modifications to improve/reclaim freed memory. If you can't modify your application for better memory management, you may want to recompile the kernel on a test system with some of the memory management patches and test them out.

  3. #3
    Just Joined!
    Join Date
    Feb 2008
    Posts
    3
    HROAdmin26 Appreciate your information.

    Just a quick question; Even if my application does not use the memory does it mean that the fragmented small chunks show up as being used by my application? (I use "top" to monitor my application)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •