[tpop3d-discuss] How do i change the syslog facility?

[Chris Elsworth]

On Wed, Nov 07, 2001 at 03:52:58PM -0800, Paul Makepeace wrote:
> On Wed, Nov 07, 2001 at 11:42:42PM +0000, Chris Elsworth wrote:
> > A busy mail server might spend almost as much time (remember ISPs turn 
> > logging up to aid in troubleshooting, coping for customer complaints, etc) 
> > logging as it does sending mail when going via syslogd.
> > 
> > A real life example. Demon use thttpd (a very lightweight httpd server)
> > for Homepages. Output from top with irrelevant processes snipped:
> > 
> >   PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
> > 24110 nobody     1  49    0   51M   18M run   549.2H 12.94% thttpd
> > 15207 root      18  58    0 4608K 1824K sleep  82.8H  1.57% syslogd
> 
> I'm curious -- is the machine that is logging the syslog messages also
> the same machine that is writing data to a file somewhere? Typically a
> busy system will have a dedicated syslogging facility that has its own
> optimi[sz]ed resources (disk, cpu, etc). That is typically one of
> the major plus points of syslog after all is its ability to
> centrali[sz]e logging.

Yes, it is - we have four machines doing exactly the same thing at the 
moment, each one running a thttpd and syslogd (and other minor daemons of 
no importance). We could fiddle with how it works all day, for example by 
moving all the logging to the fourth box, so 1,2, and 3 have no logs being 
written at all, but then that would increase the load on 4 fourfold. The 
ideal solution is a box not actually serving pages to do the logging, but 
we don't have one at the moment. We make do with what we have :)

> > Notice the runtime on each process. syslogd takes up a substantial amount 
> > of CPU time - for this reason we're looking at moving to direct file 
> > logging. One line (about 100 bytes) is logged per hit.
> 
> Have you looked at disk contention, profiled/straced syslogd and checked
> for filesystem fragmentation?

To be honest, no, not yet - in the grand scheme of helping to run an ISP 
and its day to day problems, this particular issue is small fry so it's 
been pushed to the back of the queue, but the long term plan was to take 
syslogd out of the loop as far as the weblogs are concerned - there can be 
no doubt that it is causing overhead - for each line received it has to do 
checks to verify authenticity, decide where the logline should end up, 
handle file opening/closing - all of this could be avoided with 
direct-to-disk logging. (or as is also pointed out, a tiny daemon to 
listen to syslog/udp and throw whatever it get directly onto disk.)

-- 
Chris Elsworth  -  Software & Systems Developer  /  Systems Administrator