Re: Performance monitor signal handler

* Jan Wieck <JanWieck@yahoo.com> [010316 08:08] wrote:
> Philip Warner wrote:
> >
> > But I prefer the UDP/Collector model anyway; it gives use greater
> > flexibility + the ability to keep stats past backend termination, and,as
> > you say, removes any possible locking requirements from the backends.
> 
>     OK, did some tests...
> 
>     The  postmaster can create a SOCK_DGRAM socket at startup and
>     bind(2) it to "127.0.0.1:0", what causes the kernel to assign
>     a  non-privileged  port  number  that  then  can be read with
>     getsockname(2). No other process can have a socket  with  the
>     same port number for the lifetime of the postmaster.
> 
>     If  the  socket  get's  ready, it'll read one backend message
>     from   it   with   recvfrom(2).   The   fromaddr   must    be
>     "127.0.0.1:xxx"  where  xxx  is  the  port  number the kernel
>     assigned to the above socket.  Yes,  this  is  his  own  one,
>     shared  with  postmaster  and  all  backends.  So  both,  the
>     postmaster and the backends can  use  this  one  UDP  socket,
>     which  the  backends  inherit on fork(2), to send messages to
>     the collector. If such  a  UDP  packet  really  came  from  a
>     process other than the postmaster or a backend, well then the
>     sysadmin has  a  more  severe  problem  than  manipulated  DB
>     runtime statistics :-)

Doing this is a bad idea:

a) it allows any program to start spamming localhost:randport with
messages and screw with the postmaster.

b) it may even allow remote people to mess with it, (see recent
bugtraq articles about this)

You should use a unix domain socket (at least when possible).

>     Running  a 500MHz P-III, 192MB, RedHat 6.1 Linux 2.2.17 here,
>     I've been able to loose no single message during the parallel
>     regression  test,  if each backend sends one 1K sized message
>     per query executed, and the collector simply sucks  them  out
>     of  the  socket. Message losses start if the collector does a
>     per message idle loop like this:
> 
>         for (i=0,sum=0;i<250000;i++,sum+=1);
> 
>     Uh - not much time to spend if the statistics should at least
>     be  half  accurate. And it would become worse in SMP systems.
>     So that was a nifty idea, but I think it'd  cause  much  more
>     statistic losses than I assumed at first.
> 
>     Back to drawing board. Maybe a SYS-V message queue can serve?

I wouldn't say back to the drawing board, I would say two steps back.

What about instead of sending deltas, you send totals?  This would
allow you to loose messages and still maintain accurate stats.

You can also enable SIGIO on the socket, then have a signal handler
buffer packets that arrive when not actively select()ing on the
UDP socket.  You can then use sigsetmask(2) to provide mutual
exclusion with your SIGIO handler and general select()ing on the
socket.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]