Backup Central

Hopefully this won't be too hard to resolve, but we are having some problems
with resource conflicts between Amanda and the software package that is the
reason we are running the server. (Guess who looses in the management
tug-of-war on this one.)

Several times during the Amanda backup of one of our servers, the CPU
utilization goes up to 100 percent and the system becomes very unresponsive.
The finger has been pointed at Amanda since the high runner processes at
this point are vdump and gzip (the systems are Tru64 UNIX clusters, thus
vdump). I have changed the backup type from client-compress to
server-compress, but that does not completely resolve the problem, we still
see the slowdowns.

How do I throttle back the Amanda processes without killing my backups
entirely?

Is there a setting for this in the amanda.conf file that I have missed?

Do I have to go into the source and start hacking on Amanda to add a new
"feature"?

Any pointers would be appreciated, but I have already looked at the
FAQ-O-Matic and came up dry.

Thanks,

Donald L. (Don) Ritchey
Information Technology

System Administrators Credo:
You are NOT paranoid. They ARE out to get you. Prepare
accordingly.


************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject
to copyright belonging to the Exelon Corporation family of Companies.
This e-mail is intended solely for the use of the individual or entity
to which it is addressed. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout. Thank You.
************************************************************************

On Thu, 1 Jul 2004 at 8:09am, donald.ritchey < at > exeloncorp.com wrote

Hopefully this won't be too hard to resolve, but we are having some problems
with resource conflicts between Amanda and the software package that is the
reason we are running the server. (Guess who looses in the management
tug-of-war on this one.)

Several times during the Amanda backup of one of our servers, the CPU
utilization goes up to 100 percent and the system becomes very unresponsive.
The finger has been pointed at Amanda since the high runner processes at
this point are vdump and gzip (the systems are Tru64 UNIX clusters, thus
vdump). I have changed the backup type from client-compress to
server-compress, but that does not completely resolve the problem, we still
see the slowdowns.

So I take it that this box isn't the amanda server? And, after moving to
server-compress, you're still seeing high usage from vdump *and* gzip?

How do I throttle back the Amanda processes without killing my backups
entirely?

Well, I have no experience with Tru64, but I don't think that simply
reading data off disk (and compressing a string of text, which is
what that gzip is doing -- compressing the index) should peg the CPU.
Can you replicate that problem without amanda (running vdump by hand,
e.g.). Are there parameters you can tweak to make the disks more
efficient?

Do I have to go into the source and start hacking on Amanda to add a new
"feature"?

One thing you could try would be to make the vdump amanda calls a script
that "nice"s the actual vdump process. Is tar an option? That may be
more efficient perhaps?

--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Thanks for the suggestions.

The box in question is not the Amanda server, but one of its clients.

Unfortunately, no, 'tar' is not an option, but the suggestion about a dump
wrapper seems to fit our situation. I will try the suggestion and see what
results from it.

Thanks,

Donald L. (Don) Ritchey
Information Technology


-----Original Message-----
From: Joshua Baker-LePain [mailto:jlb17 < at > duke.edu]
Sent: Thursday, July 01, 2004 8:24 AM
To: donald.ritchey < at > exeloncorp.com
Cc: amanda-users < at > amanda.org
Subject: Re: Amanda Processes using too much of the system CPU, how to
throttl e back


On Thu, 1 Jul 2004 at 8:09am, donald.ritchey < at > exeloncorp.com wrote

Hopefully this won't be too hard to resolve, but we are having some
problems
with resource conflicts between Amanda and the software package that is
the
reason we are running the server. (Guess who looses in the management
tug-of-war on this one.)

Several times during the Amanda backup of one of our servers, the CPU
utilization goes up to 100 percent and the system becomes very
unresponsive.
The finger has been pointed at Amanda since the high runner processes at
this point are vdump and gzip (the systems are Tru64 UNIX clusters, thus
vdump). I have changed the backup type from client-compress to
server-compress, but that does not completely resolve the problem, we
still
see the slowdowns.

So I take it that this box isn't the amanda server? And, after moving to
server-compress, you're still seeing high usage from vdump *and* gzip?

How do I throttle back the Amanda processes without killing my backups
entirely?

Well, I have no experience with Tru64, but I don't think that simply
reading data off disk (and compressing a string of text, which is
what that gzip is doing -- compressing the index) should peg the CPU.
Can you replicate that problem without amanda (running vdump by hand,
e.g.). Are there parameters you can tweak to make the disks more
efficient?

Do I have to go into the source and start hacking on Amanda to add a new
"feature"?

One thing you could try would be to make the vdump amanda calls a script
that "nice"s the actual vdump process. Is tar an option? That may be
more efficient perhaps?

--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject
to copyright belonging to the Exelon Corporation family of Companies.
This e-mail is intended solely for the use of the individual or entity
to which it is addressed. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout. Thank You.
************************************************************************

donald.ritchey < at > exeloncorp.com wrote:

Unfortunately, no, 'tar' is not an option, but the suggestion about a dump
wrapper seems to fit our situation. I will try the suggestion and see what
results from it.

For a complete different problem, I once wrote this quick hack,
called "slowdown".
Maybe it give some inspiration, or you can insert in a pipe just
after vdump in the dumpwrapper.


============= cut here ==============
#!/usr/bin/perl

# slow throughput down to X bytes per seconds (default = 128k/s)
# Usage: somefastprogram | slowdown 32k | ...

$BS=shift || '128k';
$BS =~ s/(\d+)k/$1 * 1024/ie;
$BS =~ s/(\d+)M/$1 * 1024 * 1024/ie;

while ($n = read(STDIN, $buf, $BS)) {
syswrite(STDOUT, $buf, $n) || die("$0: syswrite: $!\n");
sleep 1;
}

============= cut here ==============


--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens < at > xplanation.com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************