<div class="gmail_quote">On Thu, Oct 6, 2011 at 7:37 AM, Henrik Størner <span dir="ltr"><<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">* Have you looked at the vmstat1 graphs for these systems ? How is the "I/O wait" on them ? Some types of I/O on Linux systems can cause quite a slow-down; deleting large files on ext2 or ext3 systems could be quite time-consuming and cause the whole system to really stall. Also doing things that touch a lot of files - a large find, or grep'ing through a large number of files, especially if you don't mount filesystems with the "noatime" option - can cause a lot of I/O that slows down filesystem operations.</div>


</blockquote></div><br><div>I've seen this happen during log rotation and compression, shown by "sar -d" (I recommend installing sar if you haven't already).  The I/O contention during removal of a big file after compression is sufficient to cause any filesystem operation to block for a loooong time.  For me, this causes sufficient back-pressure that syslog-ng starts dropping UDP packets while it waits for the logfile to become writeable.</div>

<div><br></div><div>To prove that it's not a Xymon problem, why not create a cron task that does the same thing, but logs how long it takes.  If the log shows delays, then it's got nothing to do with Xymon.  Perhaps create /etc/cron.d/touchtest with the following:</div>

<div><br></div><div> * * * * * root time touch /path/to/file >> /tmp/touchlog 2>&1</div><div> 50 23 * * * root cp /dev/null /tmp/touchlog</div><div><br></div><div>Cheers</div><div>Jeremy</div><div><br></div>