Re: Is IDLE session really idle? - Mailing list pgsql-admin

From Tom Lane
Subject Re: Is IDLE session really idle?
Date
Msg-id 26845.1245106081@sss.pgh.pa.us
Whole thread Raw
In response to Is IDLE session really idle?  (Igor Polishchuk <ipolishchuk@hi5.com>)
Responses Re: Is IDLE session really idle?  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-admin
"Scott Whitney" <swhitney@journyx.com> writes:
> Sorry to bother you. Can you route me towards any information on this
> statement?

> " top's inclination to report only a portion
> of shared memory as having been used by the process?"

On many platforms, top shows each backend process as having "used" only
as many pages of PG's shared memory segment as that specific process has
actually touched in its lifespan.  So the normal behavior is that the
reported memory size gradually rises from just-private-space to
private-space-plus-all-of-shared-memory as the process randomly happens
to have need to touch each of the shared buffer slots.  This is on top
of any actual increase in the process's own (private) memory space.

I suspect the other guy was seeing this effect more than any real
long-term increase in private space.  But of course there's not
enough evidence in what he posted to prove it one way or the other.

Some versions of "top" distinguish shared and private memory usage,
which really helps.  But a lot don't, or people may not know which
column to pay attention to.

> I _thought_ I had seen such behavior in the past, but I've never found (not
> particularly looked) for such information. Top seems to lie to me on a
> fairly-regular basis, and not just via PG...

This particular effect only applies to applications that use large
chunks of shared memory.  There might be some other misleading things :-(

            regards, tom lane

pgsql-admin by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Is IDLE session really idle?
Next
From: Konstantin Gredeskoul
Date:
Subject: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable