Date: Fri, 25 May 2007 23:21:38 +0200 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c Message-ID: <46575362.1050005@freebsd.org> In-Reply-To: <20070525090951.F53865@fledge.watson.org> References: <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org> <4654D011.5040309@freebsd.org> <20070524092643.GC89017@FreeBSD.org> <20070525084450.H53865@fledge.watson.org> <46569762.6090801@freebsd.org> <20070525090951.F53865@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Fri, 25 May 2007, Andre Oppermann wrote: > >>> Kernel-sourced log messages result in an fsync() of log files the >>> message is written to, as syslogd feels that kernel messages are very >>> important and should go to disk as quickly and reliably as possible. >>> As a result, it's very desirable to rate limit (ideally no more than >>> 1pps) packet-generated log messages. I've been thinking of adding a >>> spp function to match ppsprint for things like kernel warnings about >>> the audit trail storage partition filling up, as one message a second >>> is still a lot. >> >> kern.debug should not be automatically written and fsync()ed to disk. >> All these TCP messages are sourced as kern.debug (except for the log_ >> in_vain variety with kern.info but that's something the user has to >> explicitly enable). > > I don't know the actual historical reason, but I've always assumed that > the fsync'ing of kernel log data is a result of kernel output being used > for system debugging, which tends to occur when the system is behaving > in an unstable way. Syncing the messages to disk means that the chances > of the message not being there later due to being lost somewhere in the > cache are greatly reduced -- i.e., on a system crash, you want debugging > data until the last possible moment. I think this is useful behavior, > although it does make klog a less useful logging mechanism for high > volume debug data -- for that we generally prefer KTR + ALQ. The syslog log level LOG_DEBUG is the lowest possible level and according to the descriptions meant to be used for informal messages during program debugging. Everything below LOG_NOTICE should not need fsync after each line. An examination of all users of LOG_DEBUG in our kernel doesn't show anything critical that would require fsync. The attached patch fixes syslog.conf in this regard. > My recommendation would simply be to stick this under pps and limit to 5 > warnings/sec or the like and stick with things basically as they are > otherwise. I would also suggest that these printfs be disabled in > production systems, and solely used in the development branch (which is > true now, but should remain true later). OK, we can do that before 7.0R. -- Andre $ cvs diff -up syslog.conf Index: syslog.conf =================================================================== RCS file: /home/ncvs/src/etc/syslog.conf,v retrieving revision 1.28 diff -u -p -r1.28 syslog.conf --- syslog.conf 12 Mar 2005 12:31:16 -0000 1.28 +++ syslog.conf 25 May 2007 21:20:54 -0000 @@ -6,14 +6,15 @@ # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console -*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages +*.notice;authpriv.none;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron -*.=debug /var/log/debug.log +# do not call fsync() after each line for debug messages +*.=debug -/var/log/debug.log *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46575362.1050005>