Re: Log rotation

Поиск
Список
Период
Сортировка
От Fernando Nasser
Тема Re: Log rotation
Дата
Msg-id 405485C2.7070306@redhat.com
обсуждение исходный текст
Ответ на Re: Log rotation  (Lamar Owen <lowen@pari.edu>)
Ответы Re: Log rotation  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Log rotation  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Lamar Owen wrote:
> On Saturday 13 March 2004 10:36 am, Fernando Nasser wrote:
> 
>>The problem is that sysloging has more overhead than a plain append to a
>>file.  There are some very strict response time AppServer applications
>>where we want to keep this things out of the picture.
> 
> 
> Well, I have a couple of ideas on that.  First, a better syslog.  SDSC secure 
> syslog has been available for some time and is BSD licensed, and is 
> specifically designed for high-performance RFC3195 compliant secure syslog.
> 

I hope someone in the OS group is watching it.  I will ask.


> Second, if the syslog server is separate, then you might get better 
> performance as the size of the logs grow, since appending a very large file 
> is slower than generating an IP datagram.
> 

It may be.  It takes some effort to convince customers to change their 
practices though.  I will try to set up something like this next time we 
run benchmarks and see if there is any noticeable change in the results.


> Third, it seems that you don't have enough profiling data to support a 'syslog 
> is bad' position. 

That is true.  It is from hearsay, from people who run production 
environments.  It may be a belief based on old experiences though.  If 
someone had real up-to-date reliable numbers maybe we could use it as an 
argument to the users.


> Java is bad too, from a performance standpoint (at this 
> time, at least, you always get a performance hit of some kind using any 
> portable code). 

Actually, this is increasingly less noticeable.  With just in time 
compilation or pre-compiled code (like with GNU gcj) it is a one time 
hit or not even that.


> But if this AppServer is based on the ArsDigita Java 
> codebase, you have other performance issues already (the Tcl codebase, OTOH, 
> is very fast, partly because AOLserver is a faster appserver than most Java 
> appservers).).
>

No, it is based on ObjectWeb JOnAS (Java Open Source Application 
Server).  The Servelet Container is Tomcat and the database is 
PostgreSQL (it also works with Oracle, DB2, MySQL, etc.).


> 
>>The other problem is that we have some nice graphical tools for
>>configuring logging but the /etc/syslog.conf is a very hard one to
>>automate dur to the pattern matching.  We can add some lines there, like
>>one to get local0 to a specific file, but it will probably be guesswork
>>and require human inspection anyway.
> 
> 
> Control Center looks promising.  But I much prefer having a central syslog 
> server than having each server in a cluster having separate logs.
> 

There are certain advantages with doing it that way and I guess some 
customers will indeed do it.  I believe you can very well set up logging 
to a centralized syslog with Control Center (if not please open a buf 
report).


> 
>>It may be desirable to logrotate them at different times as well, so
>>they would have to be in different files.
> 
> 
> Different facilities can then go to different files.  The problem, of course, 
> is syslog's limited number of facilities.  
>

If not used for other things, maybe 8 would be a good enough number.

> 
>>>Or you'll have to include some other log rotator.
> 
> 
>>That is what Tom is proposing.
> 
> 
> I am not opposed to including a small logrotator for stderr logging.  I just 
> think it is redundant when a good highly configurable logging facility 
> already exists.  But, if Red Hat wants to pay Tom to do it... :-)

Maybe it is a question of preference or what is more convenient depends 
on the specific circunstances of the installation.  I would prefer to 
give the option to the users, if possible.


Cheers,
Fernando




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: libpq thread safety
Следующее
От: Fernando Nasser
Дата:
Сообщение: Re: Log rotation