Re: Performance monitor signal handler

* Jan Wieck <JanWieck@Yahoo.com> [010316 16:35]:
> Jan Wieck wrote:
> > Tom Lane wrote:
> > > Now this would put a pretty tight time constraint on the collector:
> > > fall more than 4K behind, you start losing data.  I am not sure if
> > > a UDP socket would provide more buffering or not; anyone know?
> >
> >     Looks  like Linux has something around 16-32K of buffer space
> >     for UDP sockets. Just from eyeballing the  fprintf(3)  output
> >     of my destructively hacked postleprechaun.
> 
>     Just  to  get  some  evidence  at hand - could some owners of
>     different platforms compile and run  the  attached  little  C
>     source please?
> 
>     (The  program  tests how much data can be stuffed into a pipe
>     or a Sys-V message queue before the writer would block or get
>     an EAGAIN error).
> 
>     My output on RedHat6.1 Linux 2.2.17 is:
> 
>         Pipe buffer is 4096 bytes
>         Sys-V message queue buffer is 16384 bytes
> 
>     Seems Tom is (unfortunately) right. The pipe blocks at 4K.
> 
>     So  a  Sys-V  message  queue,  with the ability to distribute
>     messages from  the  collector  to  individual  backends  with
>     kernel  support  via  "mtype"  is  four  times by unestimated
>     complexity better here.  What does your system say?
> 
>     I really never thought that Sys-V IPC is a good way to go  at
>     all.   I  hate  it's  incompatibility to the select(2) system
>     call and all these  OS/installation  dependant  restrictions.
>     But I'm tempted to reevaluate it "for this case".
> 
> 
> Jan
$ ./queuetest
Pipe buffer is 32768 bytes
Sys-V message queue buffer is 4096 bytes
$ uname -a
UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5
$ 

I think some of these are configurable...

LER

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749