BackupPC-users

Re: [BackupPC-users] Hardware considerations for building dedicated backuppc server

2009-07-07 14:50:20
Subject: Re: [BackupPC-users] Hardware considerations for building dedicated backuppc server
From: Les Mikesell <lesmikesell AT gmail DOT com>
To: Holger Parplies <wbppc AT parplies DOT de>
Date: Tue, 07 Jul 2009 13:45:11 -0500
Holger Parplies wrote:
>
> Les Mikesell wrote on 2009-07-07 12:17:56 -0500 [Re: [BackupPC-users] 
> Hardware considerations for building dedicated backuppc server]:
>> Filipe Brandenburger wrote:
>>> On Mon, Jul 6, 2009 at 23:57, Les Mikesell<lesmikesell AT gmail DOT com> 
>>> wrote:
>>>> The only thing that seems slightly strange in the graphs is the load 
>>>> average
>>>> going to 12 as the backups start and staying there a couple of hours.  
>>>> Normally
>>>> that's the average number of 'other' processes that are waiting for CPU but
>>>> otherwise runnable (i.e. not themselves blocked on i/o).
>>> I used to think that, but in fact processes that are blocked in disk
>>> i/o (the ones in "D" state) do count in load average. So the load
>>> average of 12 in this case probably means processes writing to the
>>> disk.
>> That must be a Linux quirk (bug?) but it does explain some numbers I've 
>> seen.
> 
> if it is, it's inherited at least from SunOS (and HP-UX, if I remember
> correctly). I haven't been using Solaris for quite a while, so I can't say
> if the load on NFS clients still goes up when NFS servers go down. SunOS 5.10
> w(1) documents the load to mean "average number of jobs in the run queue",
> which should *not* include processes waiting for I/O. Probably a Solaris quirk
> (bug?) though.
> 
> Both ways of defining load make sense. Processes waiting for short term disk
> I/O are using resources (and would probably be running if the disk was simply
> faster). NFS I/O is not necessarily "short term", but that's a different
> matter.

It doesn't make sense to me to consider a process runnable when it is 
waiting for a hardware operation to complete - the scheduler should be 
ignoring it.  I suppose if the disk in question is an IDE  that the CPU 
has to micro-manage it might make sense to blame the application for the 
CPU use even if the kernel is doing it.

> Linux uptime(1) documents what "system load" means on Linux.
> 
> Wherever it matters, you won't be looking at a single figure to measure your
> system's state anyway.

Yes, the load average in mostly just useful to tell you if a faster CPU 
would help, but it isn't even good for that if it counts things that 
couldn't use the CPU anyway.

-- 
  Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>