On 2006-08-01 13:00:05 -0400, Jon LaBadie wrote:
>
> 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.
>
Sorry, my fault. Was previously running with 2.4.x.
2.4.5p1 doing a loopback amanda dump "direct" to tape (no holding disk)
is a bit slower than a local system dump tool, but not quite so
catastrophically so, @ 11553 KB/s in last test (during which I was poking
at various things on the system, think it might be a little faster usually).
It may still be that 2.4.5 scrapes in just above a streaming cutoff but
2.5.1 doesn't... 11 or so MB/sec does sound a lot like roughly 1/2 LTO2 max.
throughput I guess.
so switched nearly-2.5.1 to vanilla "bsd" with holding disk in order to
try another test with nearly-2.5.1 to try to eliminate that as the issue...
but I can't! Bigger Problems:
Amanda "driver" process just upped and dumped core - guess I got my wish for
a crash... Could be entirely unrelated to previous performance problem,
of course.
amdump.1:
driver in free(): error: chunk is already free
...
Abort trap (core dumped)
gdb driver.core ... :
(gdb) backtrace
#0 0x000000004831f65a in kill () from /usr/lib/libc.so.39.0
#1 0x00000000483655c1 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#2 0x000000004833f7f0 in wrterror (p=0x4846d7aa "chunk is already free") at
/usr/src/lib/libc/stdlib/malloc.c:434
#3 0x000000004833f8aa in wrtwarning (p=0x4846d7aa "chunk is already free") at
/usr/src/lib/libc/stdlib/malloc.c:444
#4 0x000000004834188c in free_bytes (ptr=0x3ed7, index=6, info=0x4a720000) at
/usr/src/lib/libc/stdlib/malloc.c:1613
#5 0x0000000048340935 in ifree (ptr=0x4a720c20) at
/usr/src/lib/libc/stdlib/malloc.c:1730
#6 0x0000000048340acf in free (ptr=0x4a720c20) at
/usr/src/lib/libc/stdlib/malloc.c:1791
#7 0x00000000004175d5 in free_assignedhd ()
#8 0x0000000000404e76 in start_some_dumps ()
#9 0x000000000040926b in read_schedule ()
#10 0x0000000000420e7c in event_loop_wait ()
#11 0x0000000000420588 in event_loop ()
#12 0x00000000004039f2 in main ()
(gdb)
> 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.
>
I think the thinking was at the time that the holding disk was
(yeah, dumb, but it was "good enough" for quite a while) on the same HW RAID
as most of the FSes on the amanda server itself, so best just bypass it for
local DLEs - 2.4.5 did okay without the holding disk, after all.
|
