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.
