Re: Performance monitor signal handler

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Samuel Sieb <samuel(at)sieb(dot)net>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance monitor signal handler
Date: 2001-03-18 02:18:39
Message-ID: 200103180218.VAA02620@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Samuel Sieb <samuel(at)sieb(dot)net> writes:
> > Just as another suggestion, what about sending the data to a different
> > computer, so instead of tying up the database server with processing the
> > statistics, you have another computer that has some free time to do the
> > processing.
>
> > Some drawbacks are that you can't automatically start/restart it from the
> > postmaster and it will put a little more load on the network,
>
> ... and a lot more load on the CPU. Same-machine "network" connections
> are much cheaper (on most kernels, anyway) than real network
> connections.
>
> I think all of this discussion is vast overkill. No one has yet
> demonstrated that it's not sufficient to have *one* collector process
> and a lossy transmission method. Let's try that first, and if it really
> proves to be unworkable then we can get out the lily-gilding equipment.
> But there is tons more stuff to do before we have useful stats at all,
> and I don't think that this aspect is the most critical part of the
> problem.

Well,

back to my initial approach with the UDP socket collector. I
now have a collector simply reading all messages from the
socket. It doesn't do anything useful except for counting
their number.

Every backend sends a couple of 1K junk messages at the
beginning of the main loop. Up to 16 messages, there is no
time(1) measurable delay in the execution of the "make
runcheck".

The dummy collector can keep up during the parallel
regression test until the backends send 64 messages each
time, at that number he lost 1.25% of the messages. That is
an amount of statistics data of >256MB to be collected. Most
of the test queries will never generate 1K of message, so
that there should be some space here.

My plan now is to add some real functionality to the
collector and the backend, to see if that has an impact.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-03-18 02:19:25 Re: beta6 pg_restore core dumps
Previous Message Tom Lane 2001-03-18 02:18:38 Re: beta6 pg_restore core dumps