On 8/2/07, Andrej Ricnik-Bay <andrej.groups@gmail.com> wrote:
> On 8/2/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > > 4735 root 18 0 52524 7204 4304 S 0.0 0.4 0:00.01 httpd
> > > 4820 root 15 0 141m 6648 3140 S 0.0 0.4 0:00.64 X
> > I think most of the virtual memory used by X is actually the map of the
> > graphics card's memory AFAIK, so it's not as significant as you think.
> That machine has an on-board chipset (i845) and has only 8MB
> shared memory allotted to the card ....
You don't seem familiar with the meaning of VIRT in the memory
allocation listing there.
VIRT includes all the sizes of all the libraries that the process has
opened, whether they've been loaded or not. i.e. apache shows 52 Meg
there, but only has 7.2Meg resident. If it manages to do something
that needs the dynamic libs they'll get loaded into real memory and
take up real space. until then, it's only using 7.2 meg or so.
The same is true of X here. It has 141M of total memory taken between
resident, shared and all the libs it's linked to, but it's only
actually using 6.6 meg of phyiscal memory. If those ever do get used,
then they could take up real physical memory. but on a server, it's
quite likely that they never will. And if they do, then sit idle for
some length of time, the OS will swap them out to make space for the
OS to do something else in. If the programs resident in the 6.6 meg
of physical memory don't see much use, they too will be swapped out to
make space for caching etc as well.
I can't imagine that 6.6 meg making a big difference on most servers
nowadays. I/O bandwidth, network bandwidth, memory bandwidth, number
of CPUs, all are probably more important than a 6.6 meg chunk of
memory.
