Re: Performance monitor signal handler

* 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)

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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]