On Tue, Jun 10, 2008 at 08:23:33AM -0400, Greg Haase wrote: > On Tue, 2008-06-10 at 13:34 +0200, Dejan Muhamedagic wrote: > > Hi, > > > > On Tue, Jun 10, 2008 at 06:37:22AM -0400, haaseg wrote: > > > > > > When we talk system load, are we talking memory, CPU, disk... > > > > It is CPU related and you can see it with uptime. Note that if > > you're short on memory, the load may get rather high due to > > increased swapping. There are many different causes of a high > > load. > > > > > On all 3 > > > counts this box should be fine during the times when the SIGCHILD delays > > > occurred. > > > > Hmm, how do you exactly know that this was the case? > > > > This machine has 8x 2GHz processors and 8GB of RAM. We actively monitor > it with both Ganglia and Nagios, and the machine is NOT swapping and > even at highest load, it's peak over the last week is 30% CPU.
Looks good. > > > What would the list suggest is a "safe" timeout interval for an IP > > > Address? > > > > I'd say at least 15-20 seconds. Note that it has nothing really > > to do with the type of resource, i.e. running a monitor operation > > on a resource consists of quite a few operations including > > forking the shell which nowadays is not so light as it used to > > be. If the resource type is "heavy" itself or network dependent, > > then the timeout should of course be still higher. > > > > Thanks, > > > > One would argue that at some point, a 20 second delay in your VIP going > down no longer constitutes High Availability. That's not delay. There's nothing preventing the monitor to immediately report a failure. > I've got a couple of network guys helping me out on this, and we see > nothing in the any of the logs except the timeouts. I understand the > SIG messages being maybe a second behind, but hold your breath and count > to 5 - it's a very long time. Normally, yes. Still, bear in mind that there are absolutely no guarantees when a process on Linux will run. It's known to have happened in spite of having loads of computing resources. At any rate, I'd rather have longer timeouts than intermitent failures due to timeouts being sometimes too short. One more time, the occurence of the timeout you saw was real, i.e. cluster didn't lie to you about the monitor operation timing out. > > > Dejan > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
