Re: Performance monitor signal handler

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance monitor signal handler
Date: 2001-03-16 22:25:24
Message-ID: 200103162225.RAA08269@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)Yahoo(dot)com #

Attachment Content-Type Size
queuetest.c text/plain 1.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nat Howard 2001-03-16 22:32:48 Re: Beta6 for Tomorrow
Previous Message Martin A. Marques 2001-03-16 22:24:06 Re: problems with startup script on upgrade