On Wednesday 02 August 2006 13:31, Paddy Sreenivasan wrote:
>On 8/2/06, David Golden <dgolden AT cp.dias DOT ie> 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.
|
