Re: suspiciously terrible performance of 2.5.1 beta on OpenBSD/amd64 (now a crash...)
2006-08-02 13:37:53
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.
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.
--
Amanda documentation: http://wiki.zmanda.com
Amanda forums: http://forums.zmanda.com
|
|
|