From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bryce Nesbitt <bryce2@obviously.com>
Cc: sql pgsql <pgsql-sql@postgresql.org>
Subject: Re: Postgres process resident size does not drop after killing statement
Date: Wed, 15 Apr 2009 09:58:43 -0400
Message-ID: <9189.1239803923@sss.pgh.pa.us> (raw)
In-Reply-To: <49E558B2.8000600@obviously.com>
References: <49E558B2.8000600@obviously.com>
Bryce Nesbitt <bryce2@obviously.com> writes:
> Every so often our production Postgres 8.3 system will get statement
> that runs for a few hours, or a few days, or more, and needs to be
> killed dead. We kill it with pg_cancel_backend(), and cpu usage of the
> process immediately drops, and the process starts serving other
> statements. But the curious thing is the resident size does not drop.
> Is this normal?
Resident size as displayed by "top" is pretty misleading on many
systems. Typically, it counts whatever private memory the process
has plus as many pages of the shared memory area as the process has
actually touched in its lifespan. So the latter portion ramps up
from nil to approach the size of the shared memory block just as a
byproduct of normal operations. You did not say what your
shared_buffers setting is, but if it's a GB or two then I don't
find anything surprising in the numbers you show.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, bryce2@obviously.com
Subject: Re: Postgres process resident size does not drop after killing statement
In-Reply-To: <9189.1239803923@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox