On Tue, Aug 01, 2006 at 01:31:22PM +0100, David Golden wrote:
> As the new security infrastructure seems nice, and as amanda 2.5.x now
> pretty much builds on OpenBSD/amd64, I decided to try the bleeding edge.
>
Not certain from your note, is this a first installation and you
are getting poor performance or are you comparing your results
to those obtained before "upgrading" to the bleeding edge.
> But I'm getting rather poor performance on local dumps of the server (dump,
> no holding disk used, no compression), like 200x slower than it should be.
> I've got to spend a bit more time looking at it I guess, but is
> anyone else seeing anything similar? Anything immediately jump to
> anyone's mind to look at? (apart from throttling limits in amanda.conf
> - I've increased them to absurd levels to no effect.
> --enable-buffered-dump doesn't seem to make a difference, either. )
Wasn't familiar with that configure option, had to go back to the
NEWS and ChangeLog files.
>
> I've yet to test the vanilla "bsd" setting (the main reason to move to
> a new amanda version would be to move away from it anyway...), but both
> ssh and bsdtcp exhibit the behaviour on loopback. Also yet to test remote
> dumps, it's possible this only happens on loopback. Probably
> other OpenBSD system limits and tuning parameters I should check too.
>
> Much easier to debug if it had just broken :-), but doing dumps at
> 72 kbyte per second instead of 15-20 Mbyte per sec (which system dump achieves
> if doing a local dump of the same filesystem direct to LTO2 tape on the
> hardware in question) is annoying: I could understand _some_ network
> and ssh overhead, but it seems a bit much, so I'm wondering if there
> is an OpenBSD (not known for performance) or amanda problem (race?) at
> the networking layer, or some remaining 64-bit problem causing grief
> (but apparently not enough to crash amanda).
My first thought would be insufficient performance to keep the LTO
drive streaming. I think this happens on LTO when your data feed
drops below the drives reduced speed, about 1/2 maximum.
When you use your native dump utility direct to tape the limitation
is probably the rate at which data can be read by dump.
When you use amanda, the data are fed several other programs (including
another dump to get an index) and part of the network stack. Perhaps
all this extra processing slows the feed to the drive to a point
below its streaming requirements. It can amaze you how much that can
slow things down; like the 4 or more days to run tapetype improperly.
You have chosen to 'not' use the holding disk. One of the advantages
of using a hldsk is the buffering action. The entire dump collects
on the hldsk. Only then is the data fed to the taper program. And
the feed is a direct disk read, not through lots of other programs
and network components.
Perhaps you should try with a hldsk rather than "direct to tape"
(an inaccurate amanda euphemism) and see if that is the simple
explanation for the low performance.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
