Re: Performance monitor signal handler

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Performance monitor signal handler
Дата
Msg-id 200103152234.RAA04365@jupiter.jw.home
обсуждение исходный текст
Ответ на Performance monitor signal handler  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Jan Wieck <janwieck@Yahoo.com> writes:
> >     What about a collector deamon, fired up by the postmaster and
> >     receiving UDP packets from the backends. Under heavy load, it
> >     might miss some statistic messages, well, but that's  not  as
> >     bad as having locks causing backends to loose performance.
>
> Interesting thought, but we don't want UDP I think; that just opens
> up a whole can of worms about checking access permissions and so forth.
> Why not a simple pipe?  The postmaster creates the pipe and the
> collector daemon inherits one end, while all the backends inherit the
> other end.
   I don't think so - though I haven't tested the following yet,   but AFAIR it's correct.
   Have the postmaster creating two UDP sockets before it  forks   off the collector. It can examine the peer addresses
ofboth,   so they don't need well known port numbers,  it  can  be  the   randomly  ones  assigned  by  the kernel.
Thus,we don't need   SO_REUSE on them either.
 
   Now, since the collector is forked off by the postmaster,  it   knows  the  peer  address  of the other socket. And
sinceall   backends get forked off from the postmaster as well,  they'll   all  use  the  same  peer  address,  don't
they? So all the   collector has to look at is the sender address including port   number  of  the  packets.  It needs
tobe what the postmaster   examined, anything else is from someone else and goes to  bit   heaven.  The  same  way the
backendsknow where to send their   statistics.
 
   If I'm right that in the case of fork()  all  children  share   the  same  socket  with the same peer address, then
it'seven   safe in the case the collector dies. The postmaster can still   hold the collectors socket and will notice
thatthe collector   died (due to a wait() returning it's PID)  and  can  fire  up   another one. Again some packets got
lost(plus all the so far   collected statistics, hmmm - aint that a cool  way  to  reset   statistic  counters -
killingthe collector?), but it did not   disturb any live backend in any way. They will never get  any   signal,  don't
care  about what's done with their statistics   and such. They just do their work...
 


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

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Performance monitor signal handler
Следующее
От: Roberto Mello
Дата:
Сообщение: Contribute to the PL/pgSQL CookBook !!