Linux: how to check the largest contiguous address range available to a process

Question

I want to enter the pid at the command line and get back the largest contiguous address space that has not been reserved. Any ideas?

Our 32 bit app, running on 64 bit RHEL 5.4, craps out after running for a while, say 24 hours. At that time it is only up to 2.5 gb of memory use, but we get out of memory errors. We think it failing to mmap large files because the app's memory space is fragmented. I wanted to go out to the production servers and just test that theory.

Answer 1

Slighly nicer version of my above comment:

#!perl -T

use warnings;
use strict;

scalar(@ARGV) > 0 or die "Use: $0 <pid>";

my $pid = $ARGV[0];
$pid = oct($pid) if $pid=~/^0/;         # support hex and octal PIDs
$pid += 0; $pid = abs(int($pid));       # make sure we have a number

open(my $maps, "<", "/proc/".$pid."/maps") or
        die "can't open maps file for pid ".$pid;

my $max = 0;
my $end = 0;
while (<$maps>) {
        /([0-9a-f]+)-([0-9a-f]+)/;
        $max = hex ($1) - $end if $max < hex ($1) - $end;
        $end = hex ($2);
}

close ($maps);

END {
        print "$max\n";
}

Answer 2

Probably not exactly what you want, but from inside a process it is possible to do binary search by mmaping without allocating. I.e. mmap(4GB), if that fails mmap(2GB), if that succeeds mmap(3GB), and so on.

Answer 3

we get out of memory errors. We think it failing to mmap large files because the app's memory space is fragmented.

However, one can also get OOM errors while still having lots of free virtual address ranges on paper, for example by sufficient lack of RAM+swap. Furthermore your system and/or program(s) may have overcomitting turned off (sysctl -a), or have swapping inhibited (mlock(2)), or you actually have a very blunt limit on mappings (ulimit -v) — the latter is easy to run in given some distributions set such ulimits one way or another.