Kbase P23895: Why does APW seem to be consuming a lot of memory?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
8/21/2003 |
|
Status: Unverified
GOAL:
Why does APW asynchronous page writer seem to be consuming a lot of memory?
GOAL:
An explanation of Resident Set Size and Virtual Size
FIX:
There is no memory leak.
The total size of a process is its "virtual size". That includes all memory
allocated to or mapped by the process.
Some of the memory in a process is private, meaning it is accessible only by
that process (and the kernel of course), and some could be shared, meaning
that it could be being used by several processes at the same time.
The private stuff includes things like the stack(s), the heap, thread local
storage, static variables, code that is not shareable, file buffers, and so
on.
The shared stuff includes things like code and shared static data, memory
mapped files that are marked shareable, shared memory segments, shared
libraries, etc. In many cases, there is exactly one copy of all this stuff
being used by multiple processes.
Regardless of whether shared or private, all that stuff counts as part of
the virtual address space of a process.
The "resident size" of a process is some fraction of its total address space
that is currently mapped and accessible to that process. The parts that are
not resident can be either paged out (i.e. written to the page file) or
unmapped. Private data might be paged out and code or shared data might be
unmapped. It is also possible for shared data to be paged out.
At a given instant, the sum of the resident set sizes of all processes must
be less than the total real memory in the system, assuming that all shared
pages are counted only once. But most systems count the shared pages for
each process that has attached them.
Processes that are accessing the Progress database will be attaching the
shared memory segments allocated for that database. There is one copy the
shared data, but each process maps to it and that shows up as part of the
resident set size. However, it is not required for every process to have all
of the shared memory mapped all the time. In fact, on many system, it is
not initially mapped, but only after a process accesses a particular page.
The page writers do not access every page in shared memory, only those parts
that it needs. So they begin by accessing a variety of data structures and
looking to see what needs to be written. Those pages that contain database
buffers will be accessed by a given page writer only if that page writer is
going to write that buffer.
So you will see the resident set size change over time as the page writers
run. That by itself does not mean there is a memory leak, only that the
amount of shared memory that is mapped changes.
If there were a memory leak, you would see a change in the virtual size as
the process grew larger.
If the data provided shows that the virtual size does NOT change then there is NO memory leak in this instance.
There is no need for APW's to allocate any memory at all once they have
started and completed their initialization. Since they don't allocate memory
they don't leak.