I have a process that is reporting in 'top' that it has 6GB of resident memory and 70GB of virtual memory allocated. The strange thing is that this particular server only has 8GB physical and 35GB of swap space available.

From the 'top' manual:

o: VIRT -- Virtual Image (kb)
The total amount of virtual memory used by the task. It includes
all code, data and shared libraries plus pages that have been
swapped out. (Note: you can define the STATSIZE=1 environment vari-
able and the VIRT will be calculated from the /proc/#/state VmSize
field.)
VIRT = SWAP + RES.

Given this explanation, I would expect the virutal memory allocation for a process to be limited to my swap + physical memory available.

According to 'pmap', the code, shared library, and shared memory sections of this process are all minimal - no more than 300M or so.

Obviously, the machine and the process are still functioning correctly (albeit slowly), so what am I missing here?

Yes, the application's doing a lot of correlations in the IPV4 space, so it could potentially have lots of empty pages depending on the traffic distribution. We'll have to watch out for that. Thanks!
–
BellyMar 13 '12 at 20:07

glad to help, hopefully some other user will mark me up. I come up with killer answers but I have a rating of 1,266 :-(. I don't think server fault users like me hahhah
–
The Unix JanitorMar 14 '12 at 13:24

Few reasons why people may not vote for you: 1. Formatting of your answer---use markup. 2. Your username seems generic. 3.Most importantly: The fact that you find it important enough to comment about it. Leaves a sour taste in people's mouth.
–
Belmin FernandezMar 14 '12 at 13:39

@user37899 Upvotes tend to fall into 3 categories: how informative the answer is, how well-formatted and easy to read it is, and how popular the question is. I'd work on your formatting, but you also have to have some zen and realize that some fantastic answers sit around the site with a mere one upvote -- the popularity of a question is the factor with the most effect.
–
Jeff FerlandMar 14 '12 at 13:41

The discussion refers to Java processes, but is applicable to anything running under Linux. The main point with regard to virt is that the total includes a whole bunch of stuff that may never be used. Virt is something to look at for 32-bit OSes (since processes will hit limits on addressable space), but is largely not useful otherwise. As noted, the thing to pay attention to is the resident memory, which will be limited to available physical RAM and your swap.

In the process of trying to reach that goal of "low enough overhead and no significant latency,"
the Go developers have made some simplifying assumptions, one of which is that the memory being managed for a running application comes from a single, virtually-contiguous address range. Such assumptions can run into the same problem your editor hit with vi - other code can allocate pieces in the middle of the range - so the Go developers adopted the same solution: they simply allocate all the memory they think they might need (they figured, reasonably, that 16GB should suffice on a 64-bit system) at startup time.

So that's the unelegant way memory management is done sometimes - having a continous address space simplifies releasing unused mem.