On Wed, 3 Dec 2008, Scott Marlowe wrote:
Having sent the process a SIGINT and inspected the logs, I now have a query
to explain. Looking at it, there is one single sort, and ten hash
operations, which would equate to 10GB, not 30GB. What is more worrying is
that now that the query has been stopped, the backend process is still
hanging onto the RAM.
What's your setting for share_buffers, as that's likely what the
backend is holding onto.
Shared buffers are set at 500MB, which is what all the other backends are
holding onto. It's just the one backend that is using 30GB. At the moment,
it is being swapped out, but the system seems responsive. We'll restart
the whole lot some time in the middle of the night when noone minds.
Also, you should REALLY update to 8.3.5 as there are some nasty bugs
fixed from 8.3.0 you don't want to run into. Who knows, you might be
being bitten by one right now. Unlike other bits of software floating
around, pgsql updates are bug fix / security fix only, with no major
code changes allowed, since those go into the next release which is
usually ~1 year later anyway.
It's possible, although I didn't see any relevant memory leaks in the
release notes. This is one of the only machines we have that has not been
upgraded, and it is on our schedule. Because it is running a slightly old
version of RedHat Fedora, upgrading involves more horribleness than our
sysadmin is willing to do on the fly with the server up.
Matthew
--
The email of the species is more deadly than the mail.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
