Re: Server instrumentation for 8.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Server instrumentation for 8.1

Rod Taylor
> > Exactly.  In theory it probably works fine to allow one backend to exit
> > via kill -TERM, but it cannot be claimed that that behavior has been
> > tested to any significant extent --- "fast" shutdown is not stressing it
> > in the same way.
> >
> > I think this is largely a question of someone doing a significant amount
> > of stress testing: gun live server processes with "kill -TERM" in an
> > active system, and keep an eye out for resource leaks, held locks, and
> > so on.  It would be more convincing if the processes getting zapped are
> > executing a wide variety of SQL, too --- I'd not feel very confident
> > given only tests of killing, say, pgbench threads.
> >
>
> Cause I know you wont be satisfied with anecdotal evidence, I thought I would
> just say that I have done kill's on specific backends in a high load OLTP
> process, with 1000+ active connections, for years and not had a problem with
> it yet.  
>
> Not that I wouldn't like to see some specific, thorough testing on the matter,
> but I'm perfectly comfortable with the previously provided function.

I've also used it regularly for a few years with 100 active connections
in order to get rid of processes which were doing things they shouldn't
be, and have run into problems.

It seems about one out of every 20 kills of something holding a heavy
lock (VACUUM, ALTER TABLE, etc.) will result in a lock table corruption
being reported within the next few hours, although the pg_locks view
doesn't show anything interesting, nor do the locks appear to persist as
other processes can use the structures.

--


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: Server instrumentation for 8.1

Bruce Momjian-2

Well, that's clear evidence that the only way we are going to be able to
SIGTERM a backend is it does a query cancel first, then terminates.  I
don't think anything else is going to work cleanly.

---------------------------------------------------------------------------

Rod Taylor wrote:

> > > Exactly.  In theory it probably works fine to allow one backend to exit
> > > via kill -TERM, but it cannot be claimed that that behavior has been
> > > tested to any significant extent --- "fast" shutdown is not stressing it
> > > in the same way.
> > >
> > > I think this is largely a question of someone doing a significant amount
> > > of stress testing: gun live server processes with "kill -TERM" in an
> > > active system, and keep an eye out for resource leaks, held locks, and
> > > so on.  It would be more convincing if the processes getting zapped are
> > > executing a wide variety of SQL, too --- I'd not feel very confident
> > > given only tests of killing, say, pgbench threads.
> > >
> >
> > Cause I know you wont be satisfied with anecdotal evidence, I thought I would
> > just say that I have done kill's on specific backends in a high load OLTP
> > process, with 1000+ active connections, for years and not had a problem with
> > it yet.  
> >
> > Not that I wouldn't like to see some specific, thorough testing on the matter,
> > but I'm perfectly comfortable with the previously provided function.
>
> I've also used it regularly for a few years with 100 active connections
> in order to get rid of processes which were doing things they shouldn't
> be, and have run into problems.
>
> It seems about one out of every 20 kills of something holding a heavy
> lock (VACUUM, ALTER TABLE, etc.) will result in a lock table corruption
> being reported within the next few hours, although the pg_locks view
> doesn't show anything interesting, nor do the locks appear to persist as
> other processes can use the structures.
>
> --
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to [hidden email])
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [hidden email])