Re: Performance monitor signal handler

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Performance monitor signal handler
Дата
Msg-id 200103180218.VAA02620@jupiter.jw.home
обсуждение исходный текст
Ответ на Re: Performance monitor signal handler  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Samuel Sieb <samuel@sieb.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,
thereis 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
tobe 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@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: beta6 pg_restore core dumps
Следующее
От: Tom Lane
Дата:
Сообщение: Re: beta6 pg_restore core dumps