On Wednesday 02 August 2006 13:31, Paddy Sreenivasan wrote: >On 8/2/06, David Golden <[EMAIL PROTECTED]> wrote: >> 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. > >Can you please clarify what you mean by "nearly-2.5.1". Is it 2.5.1b2 >or 2.5.1b1? There >are lots of memory issues fixed using valgrind and other tools in >2.5.1b2 release. > And something still a bit aglay here, it upchucked on me last night, only doing 3 of 44 dle's. Details to the hackers list only.
>It will be better if you try using 2.5.1b2 either from >https://sourceforge.net/project/showfiles.php?group_id=120 >or >http://www.zmanda.com/downloads.html > >If you are using 2.5.1b2, please file a sourceforge bug for the crash >(https://sourceforge.net/tracker/?func=add&group_id=120&atid=100120) >Use group v2.5.1b2 > >Thanks, >Paddy > >> 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. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.