Cary Petterborg wrote:
> I have one question and one observation in addition to what I already
> said....
>
> Question: In the case of the web server and nagios being on the same
> system, how much is an fsync() really going affect the performance of
> the system?
That depends on the filesystem, the disks and the motherboard design.
In your case, it also depends on the NFS server and client. Some NFS
servers (and/or clients) may also ignore the fsync() call and just
claim everything is written even when it isn't.
> Can someone "quantify" the impact of a single fsync? (I
> guess that is technically a second question.) If it were to do a
> sync() (where all the open files are checked to ensure that they are
> sync'd) instead of an fsync(), I would definitely agree - much bigger
> impact. But, the single fsync at the end of writing a file should not
> be of any real significance, except in the case where it means that
> the data is actually there where it should be if it *is* done (e.g.
> my case).
>
The impact is, potentially, 2 * filesize / disk writespeed once every
few seconds. In short; It's hardware and config size dependant.
>
> Observation:
>
> I think that the retention.dat and other files that are important to
> retain across crashes would definitely benefit from the fsync. Though
> nagios would still work across such a failure, I would rather that
> data be preserved properly, especially when we have a retention.dat
> file that is 40MB and the rescheduling, etc. would be handled so much
> more effectively. So for what it is worth, I think it important that
> those files be fsync'd.
>
When things are crashing, fsync() is no guarantee, and it only helps
very little on a journalled filesystem.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]