[jira] [Closed] (TS-1579) register_ShowNet calling is high load
[
https://issues.apache.org/jira/browse/TS-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen closed TS-1579.
Resolution: Fixed
register_ShowNet calling is high load
-
Key: TS-1579
URL: https://issues.apache.org/jira/browse/TS-1579
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 3.3.3
a box running ts:
{code}
run perf top
samples pcnt function
DSO
___ _
_
__
1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
traffic_server
860.00 5.3% copy_user_generic_string
[kernel.kallsyms]
743.00 4.6% ixgbe_notify_dca
[ixgbe]
425.00 2.6% ink_freelist_new
libtsutil.so.3.2.0
260.00 1.6% kmem_cache_free
[kernel.kallsyms]
248.00 1.5% tcp_ack
[kernel.kallsyms]
246.00 1.5% kfree
[kernel.kallsyms]
232.00 1.4% intel_idle
[kernel.kallsyms]
228.00 1.4% __memcpy_ssse3_back
libc-2.12.so
219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
traffic_server
181.00 1.1% _spin_lock
[kernel.kallsyms]
176.00 1.1% ink_freelist_free
libtsutil.so.3.2.0
158.00 1.0% ip_route_input
[kernel.kallsyms]
135.00 0.8% __inet_lookup_established
[kernel.kallsyms]
126.00 0.8% register_stat_callbacks()
traffic_server
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1579) register_ShowNet calling is high load
[
https://issues.apache.org/jira/browse/TS-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen updated TS-1579:
-
Fix Version/s: (was: 3.3.3)
3.2.0
register_ShowNet calling is high load
-
Key: TS-1579
URL: https://issues.apache.org/jira/browse/TS-1579
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 3.2.0
a box running ts:
{code}
run perf top
samples pcnt function
DSO
___ _
_
__
1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
traffic_server
860.00 5.3% copy_user_generic_string
[kernel.kallsyms]
743.00 4.6% ixgbe_notify_dca
[ixgbe]
425.00 2.6% ink_freelist_new
libtsutil.so.3.2.0
260.00 1.6% kmem_cache_free
[kernel.kallsyms]
248.00 1.5% tcp_ack
[kernel.kallsyms]
246.00 1.5% kfree
[kernel.kallsyms]
232.00 1.4% intel_idle
[kernel.kallsyms]
228.00 1.4% __memcpy_ssse3_back
libc-2.12.so
219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
traffic_server
181.00 1.1% _spin_lock
[kernel.kallsyms]
176.00 1.1% ink_freelist_free
libtsutil.so.3.2.0
158.00 1.0% ip_route_input
[kernel.kallsyms]
135.00 0.8% __inet_lookup_established
[kernel.kallsyms]
126.00 0.8% register_stat_callbacks()
traffic_server
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1421) Change default Diag's logging output confdigs
[ https://issues.apache.org/jira/browse/TS-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532213#comment-13532213 ] Conan Wang commented on TS-1421: So the startup logs now goes into diags.log, and debug log goes into traffic.out(stdout). Users need to know that if fail to start TS. Change default Diag's logging output confdigs - Key: TS-1421 URL: https://issues.apache.org/jira/browse/TS-1421 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.0 We should change the default log configs, to avoid logging to stdout/stderr by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1625) ATS doesn't support localhost services for full IPT connections
Aidan McGurn created TS-1625: Summary: ATS doesn't support localhost services for full IPT connections Key: TS-1625 URL: https://issues.apache.org/jira/browse/TS-1625 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Aidan McGurn We have at least 2 use cases where we want to connect the backend (OS) connection to localhost. This currently won't work under full IPT as the backend connection socket is bound to the client src ip. It needs to be bound to localhost also otherwise e.g. client src ip --- 127.0.0.1 //this will fail needs to be: 127.0.0.1 127.0.0.1 (for ipv6: ::1 --- ::1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1625) ATS doesn't support localhost services for full IPT connections
[ https://issues.apache.org/jira/browse/TS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532278#comment-13532278 ] Aidan McGurn commented on TS-1625: -- supplying patch which i tested for IPv4 and IPv6 ATS doesn't support localhost services for full IPT connections --- Key: TS-1625 URL: https://issues.apache.org/jira/browse/TS-1625 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Aidan McGurn Attachments: CCOD-309-IPT_LocalServices.patch We have at least 2 use cases where we want to connect the backend (OS) connection to localhost. This currently won't work under full IPT as the backend connection socket is bound to the client src ip. It needs to be bound to localhost also otherwise e.g. client src ip --- 127.0.0.1 //this will fail needs to be: 127.0.0.1 127.0.0.1 (for ipv6: ::1 --- ::1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1625) ATS doesn't support localhost services for full IPT connections
[ https://issues.apache.org/jira/browse/TS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan McGurn updated TS-1625: - Attachment: CCOD-309-IPT_LocalServices.patch ATS doesn't support localhost services for full IPT connections --- Key: TS-1625 URL: https://issues.apache.org/jira/browse/TS-1625 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Aidan McGurn Attachments: CCOD-309-IPT_LocalServices.patch We have at least 2 use cases where we want to connect the backend (OS) connection to localhost. This currently won't work under full IPT as the backend connection socket is bound to the client src ip. It needs to be bound to localhost also otherwise e.g. client src ip --- 127.0.0.1 //this will fail needs to be: 127.0.0.1 127.0.0.1 (for ipv6: ::1 --- ::1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532466#comment-13532466
]
Leif Hedstrom commented on TS-1006:
---
At a minimum, make the default max_mem be 0, which means never, ever, try to
use this new reclaim code. Having a configure option would be cool too. I don't
want a new config, with some arbitrary default (what did you expect to set
max_mem to?), which the user misconfigures or don't configure at all, and we
get bizarre behavior.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments: 0001-Allocator-optimize-InkFreeList-memory-pool.patch,
0002-Allocator-make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 |
[jira] [Updated] (TS-1579) register_ShowNet calling is high load
[
https://issues.apache.org/jira/browse/TS-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1579:
--
Fix Version/s: (was: 3.2.0)
3.3.1
If this is a candidate for backporting to v3.2.x, please add it to the STATUS
file on the 3.2.x branch, so we can vote on it. Once it's voted on, and passed,
the branch managers will clone this bug, and assign it to v3.2.whatever.
register_ShowNet calling is high load
-
Key: TS-1579
URL: https://issues.apache.org/jira/browse/TS-1579
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 3.3.1
a box running ts:
{code}
run perf top
samples pcnt function
DSO
___ _
_
__
1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
traffic_server
860.00 5.3% copy_user_generic_string
[kernel.kallsyms]
743.00 4.6% ixgbe_notify_dca
[ixgbe]
425.00 2.6% ink_freelist_new
libtsutil.so.3.2.0
260.00 1.6% kmem_cache_free
[kernel.kallsyms]
248.00 1.5% tcp_ack
[kernel.kallsyms]
246.00 1.5% kfree
[kernel.kallsyms]
232.00 1.4% intel_idle
[kernel.kallsyms]
228.00 1.4% __memcpy_ssse3_back
libc-2.12.so
219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
traffic_server
181.00 1.1% _spin_lock
[kernel.kallsyms]
176.00 1.1% ink_freelist_free
libtsutil.so.3.2.0
158.00 1.0% ip_route_input
[kernel.kallsyms]
135.00 0.8% __inet_lookup_established
[kernel.kallsyms]
126.00 0.8% register_stat_callbacks()
traffic_server
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1421) Change default Diag's logging output confdigs
[ https://issues.apache.org/jira/browse/TS-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532475#comment-13532475 ] Leif Hedstrom commented on TS-1421: --- Please file a documentation bug. Change default Diag's logging output confdigs - Key: TS-1421 URL: https://issues.apache.org/jira/browse/TS-1421 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.0 We should change the default log configs, to avoid logging to stdout/stderr by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1626) remove WUTS proxy code
James Peach created TS-1626: --- Summary: remove WUTS proxy code Key: TS-1626 URL: https://issues.apache.org/jira/browse/TS-1626 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach There is a bunch of code doing something with WUTS proxy status codes. What is a WUTS and why do we care? If this is cruft, let's get rid of it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TS-1006) memory management, cut down memory waste ?
在 2012年12月15日星期六，Leif Hedstrom (JIRA) 写道：
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532466#comment-13532466]
Leif Hedstrom commented on TS-1006:
---
At a minimum, make the default max_mem be 0, which means never, ever,
try to use this new reclaim code. Having a configure option would be cool
too. I don't want a new config, with some
Make the default max_mem to be 0, is a good idea.
I'll give next version soon.
arbitrary default (what did you expect to set max_mem to?), which the user
misconfigures or don't configure at all, and we get bizarre behavior.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments:
0001-Allocator-optimize-InkFreeList-memory-pool.patch,
0002-Allocator-make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common
system waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 |
--
Yunkai Zhang
Work at Taobao
