i read this
http://duartes.org/gustavo/blog/post...gram-in-memory

so the virtual space is 3GB limit per process in 32bit?

so, are we saying that the app is hitting the 3GB limit using real RAM and thus cannot use the extra that can be provided by swap, and since it needs more than 3GB it chokes? this certainly cannot be the case because there are other user mode processes that are have mapped mem space using some of real ram, so my problem app should still be able to map out 3GB of memory even if some is mapped out to disk, but i didnt see swap in use???



so let me ask about %mem in top, does this %mem account for the 1GB the app does not have access to? seems to use total which would not be accurate since its only has access to 75% of total.

Correct.

That was my estimate based on the information you showed in post #1. The consequences of that were what I was trying to explain in post #12.

The download site for the program (that you said you were using) has a 64-bit version available, which you could use if you had a 64-bit VM.


It is not actually that simple. But given the amount of ram in that VM combined with running only one very large process, it acts approximately as if it were that simple.

You are mistaken.

I don't understand what you are saying there.

Each process has its own 3GB of virtual space. Within each virtual space pages may be in many states, some of which are:
Resident: The virtual page is connected to a physical page of ram. %mem tells you the fraction of total ram occupied by this process's resident pages.
Soft faulted: The page is still in physical ram but partly disconnected from the virtual page. The page is counted as part of system wide cache and there is no way to count what fraction of cache is soft faulted from a specific process.
Anonymous non resident: The page takes up swap space.
Non anonymous non resident: The virtual page is mapped to a file on disk and at the moment the only copy is in that file on disk. There is no copy in ram and non anonymous pages never go to swap.
Demand zero: The page takes up virtual address space but physically doesn't exist. It is effectively reserved for malloc or for a thread stack etc.


You are comparing quantities that don't compare. The 3GB is a limit on the virtual address space of the process. The %mem is physical ram used by the process.

Some is data read from files by ordinary file I/O. Linux keeps a copy of such data in ram to avoid rereading the disk again if the same file is read again soon.

Some is pages "soft faulted" from processes. When there is memory pressure, Linux soft faults pages from a process's resident set into cache. If the process uses the page again, it is soft faulted back into the resident set from cache. If the page sits in cache too long, it can be dropped from memory.

I think "dirty" pages can be in cache. Dirty anonymous pages would be written to swap before being dropped from memory. Dirty file mapped pages would be written to the associated file.

You are seeing that most pages in cache were clean (already matched the associated page on disk) and can be dropped without writing. That doesn't mean all pages in cache were clean nor does it mean the clean pages were worthless. The clean pages are unnecessary, which is different from worthless.

Best estimate, your program was doing some ordinary file reads. So anonymous memory inside the process grows to buffer the data that was read, while cache grows as the system keeps a copy of that same data and free space goes down to accommodate both.
Alternate possibility, your program uses a file mapping, hard faulting pages into the resident set (using up free space), while soft faulting a smaller number of pages out of the resident set into cache.

I'm pretty sure nothing that abrupt happened. Your sampling of memory stats was coarse so that fast looks like instant.

Once free is low, Linux will no longer grow resident and cache at the expense of free. The growth of resident will come at the expense of cache.

Very few app's ask the system how much memory is available and adjust their work to fit. Most simply ask for more memory when they want it and fail if they don't get it.

The kernel will refuse a request for new anonymous virtual space if that request exceeds a formula including all of free swap space but only part of free and cache ram space. The kernel will refuse any request for virtual space (anonymous or not) if there is no virtual space available (3GB limit hit for that process).

It is also possible to set non default memory management parameters in Linux, so it will act like Windows and consider other process's demand zero memory when deciding whether to grant a request. So extra swap space that will never actually be occupied must exist in order have an anonymous memory request granted, even though that request would fit in free+cache ram.

1 members found this post helpful.

ok, here's some more info, and yes, i know Nessus comes in 64bit image, i just dont have 64bit OS yet.

at this point is where nothing happens with memory or cpu for this process and the report generation will eventually fail, but the process itself does not die. i kill hup the process and all that mem it had gets released. but someone needs to explain the SWAP for the process and the totalSWAP reported, that doesnt add up unless SWAP for the process includes data that is in the cache because 277m is certainly not shown as being in disk SWAP.

so what i am seeing is the 32bit 3GB mem mapping limit for this process, as shown by VIRT ?? i will say this is correct, but feel free to correct me if i am wrong here.

thnx.

Some programs don't even check that a memory request has failed. They just corrupt their internal operation and could go into a wait for some event that can't happen.

ps and top and similar tools (at least the versions I've used) report a totally useless value for SWAP. They report VIRT-RES (see their documentation). VIRT-RES has very little connection to the amount of swap space used.

The total swap space used does refer to actual swap space. It might be an overestimate of actual use, but it is truly swap space that is being measured. It is in no way comparable to the SWAP value reported for a process, which is not at all a measure of any swap space.

SWAP for a process does include pages that are in cache. But it also includes demand zero pages that are nowhere and it includes non resident file mapping pages that are on disk in their original files. Typically very few of the pages reported as SWAP for a process are actually occupying swap space and some pages of that process that are not reported as SWAP are occupying swap space. So "SWAP" for a process has no significant correlation with the swap space used by that process.


Correct.