Re: Performance monitor signal handler

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Performance monitor signal handler
Дата
Msg-id 200103162225.RAA08269@jupiter.jw.home
обсуждение исходный текст
Ответ на Re: Performance monitor signal handler  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Performance monitor signal handler  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Performance monitor signal handler  (Giles Lean <giles@nemeton.com.au>)
Re: Performance monitor signal handler  (Larry Rosenman <ler@lerctr.org>)
Re: Performance monitor signal handler  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Re: Performance monitor signal handler  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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

--

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



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: Stuck spins in current
Следующее
От: Giles Lean
Дата:
Сообщение: Re: ["Stephen C. Tweedie" ] Re: O_DSYNC flag for open