Re: Performance monitor signal handler

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Performance monitor signal handler
Дата
Msg-id 200103161612.LAA21999@jupiter.jw.home
обсуждение исходный текст
Ответ на Performance monitor signal handler  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Performance monitor signal handler  (Alfred Perlstein <bright@wintelcom.net>)
Re: Performance monitor signal handler  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Philip Warner wrote:
>
> But I prefer the UDP/Collector model anyway; it gives use greater
> flexibility + the ability to keep stats past backend termination, and,as
> you say, removes any possible locking requirements from the backends.
   OK, did some tests...
   The  postmaster can create a SOCK_DGRAM socket at startup and   bind(2) it to "127.0.0.1:0", what causes the kernel
toassign   a  non-privileged  port  number  that  then  can be read with   getsockname(2). No other process can have a
socket with  the   same port number for the lifetime of the postmaster.
 
   If  the  socket  get's  ready, it'll read one backend message   from   it   with   recvfrom(2).   The   fromaddr
must   be   "127.0.0.1:xxx"  where  xxx  is  the  port  number the kernel   assigned to the above socket.  Yes,  this
is his  own  one,   shared  with  postmaster  and  all  backends.  So  both,  the   postmaster and the backends can
use this  one  UDP  socket,   which  the  backends  inherit on fork(2), to send messages to   the collector. If such  a
UDP  packet  really  came  from  a   process other than the postmaster or a backend, well then the   sysadmin has  a
more severe  problem  than  manipulated  DB   runtime statistics :-)
 
   Running  a 500MHz P-III, 192MB, RedHat 6.1 Linux 2.2.17 here,   I've been able to loose no single message during the
parallel  regression  test,  if each backend sends one 1K sized message   per query executed, and the collector simply
sucks them  out   of  the  socket. Message losses start if the collector does a   per message idle loop like this:
 
       for (i=0,sum=0;i<250000;i++,sum+=1);
   Uh - not much time to spend if the statistics should at least   be  half  accurate. And it would become worse in SMP
systems.  So that was a nifty idea, but I think it'd  cause  much  more   statistic losses than I assumed at first.
 
   Back to drawing board. Maybe a SYS-V message queue can serve?


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 по дате отправления:

Предыдущее
От: Alfred Perlstein
Дата:
Сообщение: Re: Re[4]: Allowing WAL fsync to be done via O_SYNC
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re[4]: Allowing WAL fsync to be done via O_SYNC