On Fri, 23 Oct 2009, Rainer Gerhards wrote: >> For the record, changing the sync behavior of rsyslog DOES fix the >> original complaint. When we have file sync disabled we see up to 30 >> second pauses between writes to files which get multiple messages per >> second delivered to the rsyslog host. > > There is nothing in the log that points to rsyslog doing these delays. > > So my conclusion really is that you need to look at the NFS layer. To me, it > looks like NFS does some local caching, and maybe 30 seconds is the timeout > at which NFS writes data from files that are constantly being written in > short intervals. With sync, NFS probably writes and rewrites each block as > David has said, thus resulting in the far larger i/o footprint. But I am far > from being a NFS expert, so it would probably make sense to ask one ;)
this reminded me of something. a standard complient NFS implementation would require that any write to a NFS volume go all the way to the destination and be safe on disk before the write call returns to the calling program. this doesn't mean when you do a fsync, it means each individual write call. for the program to think the data has been written and it not be available on the NFS drive to other systems there has to be some non-standard caching in place here. note that unless you have a high-end NFS server that includes some battery-backed ram on it, standard complient behavior also means a very low write transaction rate. note that the caching could be on the reader machines instead of on the writer, and it could be something like caching of the metadata (including size and last modified timestamp) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
