[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190551#comment-13190551
]
Leif Hedstrom commented on TS-980:
----------------------------------
Two things:
1) When i first wrote that code, I couldn't use that thread mutex, due to a
dead lock scenario.
2) When i try this patch, it usually segfaults pretty fast, I've seen a few
different backtraces, but they generally seem to happen in DNS. See example
stack trace below.
I'm going to move this out to 3.1.4 for now, please move it as appropriate.
{code}
(gdb) bt
#0 ink_restore_signal_handler_frame (signalhandler_frame=3, len=9,
stack=0x7f4dc71545d0) at ink_stack_trace.cc:68
#1 ink_stack_trace_get (signalhandler_frame=2, stack=0x7f4dc71545d0,
len=<optimized out>) at ink_stack_trace.cc:89
#2 ink_stack_trace_dump (sighandler_frame=2) at ink_stack_trace.cc:114
#3 0x00000000004e1dd3 in signal_handler (sig=11) at signals.cc:222
#4 <signal handler called>
#5 HostDBContinuation::dnsEvent (this=0x7f4dc6729650, event=1, e=0x23a1a10) at
HostDB.cc:1331
#6 0x00000000006aca20 in handleEvent (data=0x23a1a10, event=1, this=<optimized
out>) at I_Continuation.h:146
#7 EThread::process_event (this=0x7f4dc765c010, e=0x23a1a10, calling_code=1)
at UnixEThread.cc:142
#8 0x00000000006ad5db in EThread::execute (this=0x7f4dc765c010) at
UnixEThread.cc:191
#9 0x00000000006ab732 in spawn_thread_internal (a=0x209f180) at Thread.cc:88
#10 0x00007f4dcc9ddd90 in start_thread (arg=0x7f4dc7156700) at
pthread_create.c:309
#11 0x00007f4dca14f48d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
00007ffff533848d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}
> change client_session schedule from global to thread local, and reduce the
> try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.4
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server
> session 2, pure proxy mode), I did see significant improvement on low load,
> but it dropped rapidly when load is high. meanwhile, some stability problems
> happened. Through gdb, I found the client_session`s mutex can be acquired by
> two or more threads, I believe some schedules happened during the sm
> life_time. May be we need do some work to find these eventProcessor.schedules
> and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation.
> frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
> by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more
> net io latency if it is an epoll event need to be processed in other threads.
> If it is not an epoll event(time event), I don`t think putting vc in
> ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
