Re: Performance monitor signal handler

Alfred Perlstein wrote:
> * Jan Wieck <JanWieck(at)yahoo(dot)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 possibilities to muck around
with your database. And if someone outside the local system
is doing it, it's time for some 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 needs to
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 is empty,
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 receive again.

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(at)Yahoo(dot)com #

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