Remove this ad

Lead

Jan 7 14 11:16 PM

Tags : :

As a FYI

with the number of files I've got shared, when the gui is started and connects to amuled, pretty much everything else simply stops - even if the gui is on the same box as the daemon.

I had noticed that performance was degraded in the past when the gui started but now it's virtually unusable.
Quote    Reply   
Remove this ad
Remove this ad

#2 [url]

Jan 9 14 4:14 AM

Re: gui load

"it depends"

It's a combination of both the number of shares AND the number of _active_ downloads, but the share number is so high now, that I can set downloads to zero and uploads/download traffic stops when the gui connects.

Is the gui connection handled in a separate thread to the tranfers or in the same one?

Quote    Reply   

#3 [url]

Jan 9 14 9:06 PM

Re: gui load

Pretty much everything runs in the main thread. Except upload and special background tasks (hashing, copy completed files and such).
How much (number of files, total size) are you sharing?

Quote    Reply   

#6 [url]

Jan 10 14 10:14 PM

Re: gui load

It's created, but allocated in background. That's why it crashes when you start a new download and remove it before the background thread ever gets around to create the part file.
(Which is not forgotten.)
Wow, 15 TB. (Not 15000 TB at least.) I'm not sure about the numbers but iirc less than 10% of your files can be published on Kad.

You said a Linux amulegui can handle it, but Windows can't?
Then it's probably the shared files list control which is not designed for holding 50000 entries. We would need a virtual control for that task.

Quote    Reply   

#7 [url]

Jan 11 14 2:09 AM

Re: gui load

I suspect that's "10% at any one time" - ie, as files are published, old ones roll off.

It's not that the guis can or can't handle it, but when the guis connects, amuled uploads/downloads pretty much stop, as seen at the router.

The gui itself tends to stop for 30 seconds at a time.

Quote    Reply   

#9 [url]

Jan 11 14 11:59 PM

Re: gui load

Seems to work as far as throughput is concerned, however I'm getting a lot (thousands) of messages lke this:

2014-01-11 22:58:40: Logger.cpp(332): 22:58:40: Error: Failed to add descriptor 120 to epoll descriptor 9 (error 17: File exists)
2014-01-11 22:58:40: Logger.cpp(332): 22:58:40: Error: Failed to add descriptor 120 to epoll descriptor 9 (error 17: File exists)

Quote    Reply   
Remove this ad

#10 [url]

Jan 12 14 12:05 AM

Re: gui load

Crashed and burned:


Assertion failed: MuleDebug.cpp:get_backtrace:388: Assertion 's_have_backtrace_symbols' failed.
Backtrace follows:
[3] wxOnAssert(char const*, int, char const*, char const*, char const*) in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7ffff66fc06c]
[4] get_backtrace(unsigned int) in MuleDebug.cpp:388
[5] OnUnhandledException() in MuleDebug.cpp:107
[6] CamuleApp::OnUnhandledException() in amule.cpp:1956
[7] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7ffff6849b3a]
[8] ?? in /lib/x86_64-linux-gnu/libpthread.so.0[0x7ffff5c5ff6e]
[9] clone in /lib/x86_64-linux-gnu/libc.so.6[0x7ffff598a9cd]

Quote    Reply   

#12 [url]

Jan 12 14 4:56 PM

Re: gui load

I believe I am. Will double check. Meantime I have a backtrace:


Terminated after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7ffff4dab700 (LWP 12203)]
0x00007ffff5c67a8b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
38 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb)
(gdb) continue
Continuing.
Assertion failed: MuleDebug.cpp:get_backtrace:388: Assertion 's_have_backtrace_symbols' failed.
Backtrace follows:
[3] wxOnAssert(char const*, int, char const*, char const*, char const*) in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7ffff66fc06c]
[4] get_backtrace(unsigned int) in MuleDebug.cpp:388
[5] OnUnhandledException() in MuleDebug.cpp:107
[6] CamuleApp::OnUnhandledException() in amule.cpp:1956
[7] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7ffff6849b3a]
[8] ?? in /lib/x86_64-linux-gnu/libpthread.so.0[0x7ffff5c5ff6e]
[9] clone in /lib/x86_64-linux-gnu/libc.so.6[0x7ffff598a9cd]


Program received signal SIGABRT, Aborted.
0x00007ffff5c67a8b in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
38 in ../nptl/sysdeps/unix/sysv/linux/pt-raise.c
(gdb) bt full
#0 0x00007ffff5c67a8b in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
resultvar = 0
pid =
#1 0x0000000000437c4a in CamuleApp::OnAssertFailure (this=0x9e6280, file=0x7fffec001238 L"MuleDebug.cpp", line=388, func=0x7fffc0232158 L"get_backtrace",
cond=0x7fffc0232238 L"s_have_backtrace_symbols",
msg=0x7ffff6692418 , std::allocator >::_Rep::_S_empty_rep_storage+24> L"")
at amule.cpp:1094
errmsg = {static npos = 18446744073709551615, m_impl = {static npos = 18446744073709551615,
_M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_p = 0x7fffc1c65438 L"Assertion failed: MuleDebug.cpp:get_backtrace:388: Assertion 's_have_backtrace_symbols' failed. \nBacktrace follows:\n[3] wxOnAssert(char const*, int, char const*, char const*, char const*) in /usr/lib/"...}}, m_convertedToChar = {m_str = 0x0, m_len = 140737301357104}}
#2 0x00007ffff66ff081 in wxDefaultAssertHandler (file=..., line=line@entry=388, func=..., cond=..., msg=...) at ../src/common/appbase.cpp:1093
s_bInAssert = 1
guard = {m_flag = @0x7ffff6b0d7c8, m_isInside = }
#3 0x00007ffff66fc06c in wxOnAssert (file=0x6ceb57 "MuleDebug.cpp", line=388, func=0x6cedc2 "get_backtrace",
cond=, msg=) at ../src/common/appbase.cpp:1169
No locals.
#4 0x0000000000623c5e in get_backtrace (n=1) at MuleDebug.cpp:388
libname = { >> = {
_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_start = 0x7fffc0231f60, _M_finish = 0x7fffc0231ff0, _M_end_of_storage = 0x7fffc0231ff0}}, }
funcname = { >> = {
_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_start = 0x7fffc0232000, _M_finish = 0x7fffc0232090, _M_end_of_storage = 0x7fffc0232090}}, }
AllAddresses = {static npos = 18446744073709551615, m_impl = {static npos = 18446744073709551615,
_M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_p = 0x7fffec000988 L"0x6235ba 0x622eae 0x43cf42 0x7ffff6849b3a 0x7ffff5c5ff6e 0x7ffff598a9cd "}}, m_convertedToChar = {m_str = 0x0,
m_len = 0}}
out = {m_nSize = 0, m_nCount = 0, m_pItems = 0x0, m_autoSort = false}
bt_array = {0x6235ba , 0x622eae , 0x43cf42 ,
0x7ffff6849b3a threadStart(wxThread*)+2282>, 0x7ffff5c5ff6e , 0x7ffff598a9cd , 0x0, 0x1, 0x0,
0x0, 0x0, 0x10, 0x6, 0x0, 0x1, 0x622df0 , 0x42c9c0 <__gxx_personality_v0@plt>, 0xfffffffffffffff8, 0x1, 0x10, 0x1031b,
0x0, 0x7ffff6394bf8, 0x7fffc022fbd0, 0x1, 0x7ffff4daae10, 0x7ffff4daadb0, 0xd038840, 0x7ffff4daacf0, 0xd037b60, 0x7ffff4daac40,
0x622e9d , 0x7ffff644d5d1 , 0x7ffff644d5dd ,
---Type to continue, or q to quit---
0x500000011, 0x7ffff644d5dd , 0x7ffff4daa700, 0x1800000003, 0x7ffff4daa690, 0xc00000001, 0x7fff00000000,
0x7ffff4daa700, 0x3, 0x7ffff7de41a9 <_dl_lookup_symbol_x+345>, 0x6461623a3a647473, 0x636f6c6c615f, 0x7fff00000005, 0x0, 0x7fff00000001,
0x7ffff7ffe268, 0x0, 0x7ffff7fcf418, 0x7ffff7fd0000, 0x42588e, 0x0, 0x7ffff7ffe5c0, 0x7ffff4daaa60, 0x7ffff4daaa50, 0x5f0daedb, 0x1f4daabd8,
0x7ffff4daabb0, 0x4252ca, 0xffffffff, 0x7ffff7ffe268, 0x7ffff63a62c8, 0x7ffff7fd2a10, 0x0, 0x7ffff7fcf418, 0x7fff00000005, 0x7ffff4daae10,
0x7ffff4daadb0, 0xd038840, 0x7ffff4daacf0, 0xd037b60, 0x7ffff4daac40, 0x7ffff58e3f57 <__fprintf+135>, 0xe, 0x3000000018, 0x7ffff4daaba0,
0x7ffff4daaae0, 0x0, 0x0, 0x7ffff644d5c2, 0x7fffc022fb80, 0x7ffff4daa6a0, 0x7ffff59d9000 <__memcpy_ssse3+6784>, 0x7fff00000000, 0x7ffff4daabac,
0x0, 0xd038840, 0x7ffff4daacf0, 0xd037b60, 0x0, 0x7fffc022fbd0, 0x1, 0x7fffc022fbd0, 0x7ffff4daadb0, 0xd038840, 0x7ffff4daacf0, 0xd037b60}
num_entries = 6
__FUNCTION__ = "get_backtrace"
trace = {static npos = 18446744073709551615, m_impl = {static npos = 18446744073709551615,
_M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_p = 0x7ffff4daaba0 L"\xd038840"}}, m_convertedToChar = {
m_str = 0x622f63 "H\203\372\002tZH\203\372\003\017\204", , m_len = 8061968}}
bt_strings = 0x7fffc0231d80
address = { >> = {
_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, },
_M_start = 0x7fffc02320a0, _M_finish = 0x7fffc0232130, _M_end_of_storage = 0x7fffc0232130}}, }
hasLineNumberInfo = false
#5 0x0000000000622eae in OnUnhandledException () at MuleDebug.cpp:107
status = 0
dem = 0x7fffec0008c0 "І\035\300\377\177"
name = 0x7ffff644d5d1 "St9bad_alloc"
t = 0x7ffff6675b00
output = 0x7ffff5c521a0 <_IO_2_1_stderr_>
#6 0x000000000043cf42 in CamuleApp::OnUnhandledException (this=0x9e6280) at amule.cpp:1956
No locals.
#7 0x00007ffff6849b3a in wxThreadInternal:threadStart (thread=0xd037b50) at ../src/unix/threadpsx.cpp:885
__clframe = {__cancel_routine = 0x7ffff6844a60 , __cancel_arg = 0xd037b50, __do_it = 1, __cancel_type = }
pthread = 0xd038840
__FUNCTION__ = "PthreadStart"
rc =
dontRunAtAll =
#8 0x00007ffff5c5ff6e in start_thread (arg=0x7ffff4dab700) at pthread_create.c:311
__res =
---Type to continue, or q to quit---
pd = 0x7ffff4dab700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737301362432, 1317626194430158301, 1, 140737354125408, 140737488346224, 4096, -1317637418817264163,
-1317639886761859619}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 =
sp =
freesize =
__PRETTY_FUNCTION__ = "start_thread"
#9 0x00007ffff598a9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.

Quote    Reply   

#13 [url]

Jan 12 14 8:01 PM

Re: gui load

bt is useless. We have an exception, aMule jumps into its exception handler and asserts there.
The original point of problem is not visible.
But std::bad_alloc sounds like out of memory.
Does this happen when you connect amulegui with the patch I sent?
Right away or after a while?

Quote    Reply   

#15 [url]

Jan 13 14 12:23 AM

Re: gui load

Some more data....

It looks like its leaking connectors like crazy. I had to increase them a few times yesterday because it was saying "too many connections."

Today, after it finally got to the full number of shared files, all downloads stopped along with most uploads. Well before that, performance was already impaired - and it looks like it's impaired even with the gui switched off.

Quote    Reply   

#17 [url]

Jan 14 14 2:05 PM

Re: gui load

Somewhat similar to what I've found, but in a completely different environment (mipsel, wxbase, low resources...)

Quote    Reply   
Remove this ad
Add Reply

Quick Reply

bbcode help