On Tue, Feb 17, 2004 at 06:47:19PM -0800, Marc Perkel wrote:
> Actually - the problem is disk IO. And the disk IO is what makes the
> load levels go up. The load level is something that's readable can can
> be used to have rsync slow itself down. Nice doesn't do the trick. Nice
> helps - but even at nice +19 it still slows the system to a crawl when
> backing up from one drive to another.
Is that is on AIX with 12 AS400 CPUs or the VMS SSI cluster?
Or is that a single CPU linux box with a 2.4.?? kernel?
> So - if rsync could watch the load levels and pause every now and then
> to put a little space between disk access at high load levels it would
> make it a lot friendlier to the system. The reason nice doesn't work is
> that once the system call is made to access the disk - nice doesn't apply.
What load levels? Do you have some nice C code that can do
that for ALL the platforms without misreading?
This is what process and i/o schedulers are for.
Maybe you should contact the people responsible for whatever
kernel it is you are running.
> jw schultz wrote:
>
> >On Tue, Feb 17, 2004 at 03:16:32PM -0800, Marc Perkel wrote:
> >
> >
> >This is what process and i/o schedulars are for.
> >
> >In most cases rsync is i/o bound. Either disk or network.
> >That means it spends most of its time sleeping already.
> >This becomes increasingly true as the performance gulf grows
> >between CPU and that of memory, disk and network.
> >
> >Perhaps you have a suggestion for defining what constitutes
> >high load and how to determine that on all the different
> >platforms? Hint: load average is meaningless.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
