1

I have a program that, when queried on initialisation, is immediately using > 2 GB of RAM. Basically the code is like this:

#include <blah>

int main() {
    cout << get_mem_usage() << endl;
    //Lots of things happen, but no significant memory usage
    return 0;
}

Output: [2013-02-15 18:38:05.865283] 2147.71 Mb

I am, however, linking to a lot of different shared object files: I checked ldd and I am linking to 58 libraries, with a combined .so size of 66 MB.

I'm pretty sure that the get_mem_usage program is returning the correct values: these agree with top and massif output.

I should also mention that I am linking against the ROOT framework for High Energy Physics analysis.

I am using Linux x86_64, and the get_mem_usage() function is homegrown.

I would like to reduce the memory usage of the program, if at all possible.

Stéphane
  • 19,459
  • 24
  • 95
  • 136
invisiblerhino
  • 840
  • 1
  • 10
  • 18

4 Answers4

5

My first guess: static initizations in some of the libraries you are linking.

Insert a long pause as the very first line of main() and look through the /proc/<pid>/ to see where the memory is allocated. For example:

  • /proc/12345/task/12345/maps
  • /proc/12345/task/12345/smaps
Stéphane
  • 19,459
  • 24
  • 95
  • 136
  • A bit of information on on /proc/pid/maps: http://stackoverflow.com/questions/1401359/understanding-linux-proc-id-maps – Stéphane Feb 14 '13 at 19:02
4

I could not find any documentation on get_mem_usage().

What kind of memory usage is it reporting?

Determining memory usage in a virtual memory system is quite a challenge.

The actual amount of memory used is your resident set size. That is basically any physical memory you are using. Although with shared libraries (libc for an example), that memory consumption is (partially) shared with other applications as well.

Then there is a virtual set size - the total of any virtual memory mapped, any anonymous mappings, any other mapped files. Much of that will not really be backed with physical memory (i.e. not resident) and may be shared amongst other programs.

pmap -x <pid> will give you a neat table, including resident/dirty parts.

Overall, it is worth researching what 'uses' all that memory, but it might not be that much a problem at all. If you are running on a 32bit system, things might get a little tight anyway later on (as your virtual address space is limited).

sstn
  • 3,050
  • 19
  • 32
  • Sorry - get_mem_usage() is homegrown. It just looks at the output of /proc//statm. In my case, it was a poorly configured fortran library that immediately initialises a huge array, and the large amount of memory used cannot be shared by other processes (as I understand it). – invisiblerhino Feb 15 '13 at 10:58
2

Another possibility: if you have shared memory between your apps, then that shared memory counts against every app that accesses the shared memory segment, even though it is only allocated once. So if a 2gb shared memory segment is allocated somewhere, and 20 different applications use that shared memory, all 20 applications will seem as if they're using 2+gb of memory, making it look as if 40+gb of memory has been allocated.

Stéphane
  • 19,459
  • 24
  • 95
  • 136
2

In this case, it turned out to be a single library (that I wasn't directly using) that allocated 1.9 G memory. I found it by looking through /proc/12345/smaps

2aaab2197000-2aab2ba86000 rw-p 2aaab2197000 00:00 0 
Size:           1991612 kB

Looking up the address in /proc/12345/maps I found

2aaab2174000-2aaab2197000 rw-p 0016c000 4f9:2c566 59607963               /mnt/lustre/epp_scratch/atlas/sm442/Irvex/lhapdf-5.8.8/lib/.libs/libLHAPDF.so.0.0.0

This is a fortran library that was doing an enormous amount of static initialisation.

invisiblerhino
  • 840
  • 1
  • 10
  • 18
  • If this is the correct answer, please select it. You won't get any points for selecting your own answer, but it will remove the question from the unending list of unanswered questions. – phonetagger Aug 14 '13 at 18:20