Re: Performance monitor signal handler

Alfred Perlstein wrote:
> * 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)
   So  it's  possible  for  a  UDP socket to recvfrom(2) and get   packets with  a  fromaddr
localhost:my_own_non_SO_REUSE_port  that really came from somewhere else?
 
   If  that's  possible,  the  packets  must  be coming over the   network.  Oterwise it's the local superuser sending
them,and   in  that case it's not worth any more discussion because root   on your system has more powerful
possibilitiesto muck around   with  your  database. And if someone outside the local system   is doing it, it's time
forsome filter rules, isn't it?
 

> You should use a unix domain socket (at least when possible).
   Unix domain UDP?

>
> >     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.
   Similar problem as with shared  memory  -  size.  If  a  long   running  backend  of  a multithousand table database
needsto   send access stats per table - and had accessed them all up to   now - it'll be alot of wasted bandwidth.
 

>
> 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.
   I  already thought that priorizing the socket-drain this way:   there is a fairly big receive buffer. If the buffer
isempty,   it  does  a  blocking  select(2). If it's not, it does a non-   blocking (0-timeout) one and only if the
non-blocking tells   that  there  aren't  new  messages waiting, it'll process one   buffered message and try to
receiveagain.
 
   Will give it a shot.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com