I think we learned the lesson not to do kill -9. One weird thing was that
the three stuck automatically vacuum processes had been running for
probably more than a day and they were all working on the same pretty
static database. I doubt there were something wrong with our db. However it
would be nice postgtrsql would be tolerant to that.
The symptoms we experienced was postgresql was extremely slow and failed
all the db tests. The slowness came from the 3 vacuum process which use up
all the cpu.
Apparently killing is not the right solution. Is a proper/safer way to
recover the performance of postgresql?
On Thu, Jan 19, 2012 at 8:15 AM, Rick Dicaire <kritek(at)gmail(dot)com> wrote:
> On Wed, Jan 18, 2012 at 7:33 PM, Samuel Hwang <samuel(at)replicon(dot)com> wrote:
> > We experience slow performance and found the server is running 3 vacuum
> > process on the same db which use up 99% of CPU.
> > Then we kill -9 one of those process which cause postgresql to crash and
> > tried to restart after the crash
> While I cannot help with restarting, you shouldn't ever use kill -9
> unless no other kill signal works.
> kill default signal is SIGTERM (15), refer to man 7 signal (in linux).
> vacuum processes can be set on a per table basis, perhaps you need to
> closely examine that part of configuration.
> Sorry I can't help further.
> aRDy Music and Rick Dicaire present:
*Shian-Miin Samuel Hwang* | Software Developer | Phone 1-403-2626519 (ext.
276) | Fax 1-403-233-8046
*Replicon* | Hassle-Free Time & Expense Management Software - 7,300
Customers - 70 Countries
www.replicon.com | facebook <http://www.facebook.com/Replicon.inc> |
blog <http://www.replicon.com/blog/> | contact
*We are hiring!* | search
In response to
pgsql-admin by date
|Next:||From: Samuel Hwang||Date: 2012-01-19 17:09:48|
|Subject: Re: Help! PostgreSQL stuck at starting up after crash|
|Previous:||From: Alexander Fortin||Date: 2012-01-19 15:04:30|
|Subject: Re: Interpreting pg_stat_replication values|