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 Thu, Jan 19, 2012 at 8:15 AM, Rick Dicaire
<kritek@gmail.com> wrote:
On Wed, Jan 18, 2012 at 7:33 PM, Samuel Hwang <
samuel@replicon.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 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
