Thanks, Rick.
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 Wed, Jan 18, 2012 at 7:33 PM, Samuel Hwang <samuel@xxxxxxxxxxxx> wrote:While I cannot help with restarting, you shouldn't ever use kill -9
> 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 it
> tried to restart after the crash
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:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
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 | twitter | blog
| contact us
We are hiring! | search jobs
