[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=13618711#comment-13618711
]
jaekyung oh commented on TS-1006:
-
Hi. Yunkai Zhang.
I tried again with ./configure --enable-reclaimable-freelist
but same happens...
these are the part of traffic.out when i executed traffic_line -x
360192 | 360192 |672 | memory/netVCAllocator
0 | 0 |120 |
memory/udpReadContAllocator
0 | 0 |176 |
memory/udpPacketAllocator
0 | 0 |384 | memory/socksAllocator
0 | 0 |128 |
memory/UDPIOEventAllocator
16256 | 16256 | 64 | memory/ioBlockAllocator
8064 | 8064 | 48 | memory/ioDataAllocator
32480 | 32480 |232 | memory/ioAllocator
109512 | 109512 | 72 | memory/mutexAllocator
318032 | 318032 | 88 | memory/eventAllocator
268288 | 268288 | 1024 | memory/ArenaBlock
[Apr 1 18:18:35.010] Manager {0x7f25beffd700} NOTE: User has changed config
file records.config
[Apr 1 18:18:36.678] Server {0x2b989b06b700} NOTE: cache enabled
[2b989b06b700:01][ink_queue_ext.cc:00577][F] 13.28M t:278 f:274 m:0
avg:0.0M:4csbase:256 csize:278 tsize:88 cbsize:24576
[2b989b06b700:01][ink_queue_ext.cc:00584][-] 13.28M t:278 f:274 m:0
avg:0.0M:4csbase:256 csize:278 tsize:88 cbsize:24576
[2b989b06b700:01][ink_queue_ext.cc:00577][F] 13.32M t:278 f:274 m:0
avg:82.2 M:4csbase:256 csize:278 tsize:88 cbsize:24576
[2b989b06b700:01][ink_queue_ext.cc:00584][-] 13.32M t:196 f:192 m:0
avg:82.2 M:4csbase:256 csize:278 tsize:88 cbsize:24576
NOTE: Traffic Server received Sig 11: Segmentation fault
what happened after logging?
/usr/local/nts/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf2d0)[0x2b9897f1f2d0]
[0x2b989b274f10]
[Apr 1 18:18:39.800] Manager {0x7f25c7ec0720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 11:
Segmentation fault
[Apr 1 18:18:39.800] Manager {0x7f25c7ec0720} ERROR: (last system error 2: No
such file or directory)
[Apr 1 18:18:39.800] Manager {0x7f25c7ec0720} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Apr 1 18:18:39.800] Manager {0x7f25c7ec0720} ERROR: (last system error 2: No
such file or directory)
[Apr 1 18:18:40.803] Manager {0x7f25c7ec0720} NOTE: [LocalManager::startProxy]
Launching ts process
[TrafficServer] using root directory '/usr/local/nts'
[Apr 1 18:18:40.813] Manager {0x7f25c7ec0720} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '10'
[Apr 1 18:18:40.813] Manager {0x7f25c7ec0720} NOTE: [Alarms::signalAlarm]
Server Process born
.
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.3
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-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 |
[jira] [Commented] (TS-1753) Cacheurl plugin improvements
[ https://issues.apache.org/jira/browse/TS-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618892#comment-13618892 ] ASF subversion and git services commented on TS-1753: - Commit 3e76711e99ec7309196babb85c39fcf9d0387f78 in branch refs/heads/master from [~mivok] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3e76711 ] TS-1753: Add remap support to the cacheurl plugin - Update README for cacheurl plugin with examples - Allow specifying cacheurl.config location. This is done as the first parameter in plugins.config. - Allow cacheurl to be used as a remap plugin. This also requires that the config be stored either with the remap instance or the transaction continuation (depending on how the plugin is called) and that more than one configuration be able to be loaded. The configuration is now dynamically allocated as a result. - Convert README to restructured text (for later inclusion in official docs). Mention remap plugin invocation in the docs. Cacheurl plugin improvements Key: TS-1753 URL: https://issues.apache.org/jira/browse/TS-1753 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Mark Harrison Assignee: Phil Sorber Fix For: 3.3.2 I've made a couple of improvements to the cacheurl plugin: * parameter to take a location for the config file * ability to be called as a remap plugin -- 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] [Resolved] (TS-1753) Cacheurl plugin improvements
[ https://issues.apache.org/jira/browse/TS-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1753. - Resolution: Fixed Assignee: James Peach (was: Phil Sorber) Cacheurl plugin improvements Key: TS-1753 URL: https://issues.apache.org/jira/browse/TS-1753 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Mark Harrison Assignee: James Peach Fix For: 3.3.2 I've made a couple of improvements to the cacheurl plugin: * parameter to take a location for the config file * ability to be called as a remap plugin -- 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-1764) Unify definitions of MAX() and MIN()
[
https://issues.apache.org/jira/browse/TS-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618922#comment-13618922
]
ASF subversion and git services commented on TS-1764:
-
Commit 2d491e28bfc7ac0eb83ff3bfff59b8306c752d82 in branch refs/heads/master
from James Peach jpe...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2d491e2 ]
TS-1764: fix spdy plugin build
Unify definitions of MAX() and MIN()
Key: TS-1764
URL: https://issues.apache.org/jira/browse/TS-1764
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 3.3.2
There are a few duplications of these definitions, this would be splendid to
unify into one definition for each (yes amc, I know there's std::max :-).
{code}
loki (10:48) 892/0 $ tsg 'MAX\(' | grep define
/home/leif/apache/trafficserver.git/proxy/PluginVC.cc: #define MAX(x,y) (((x)
= (y)) ? (x) : (y))
/home/leif/apache/trafficserver.git/proxy/MuxVC.cc: #define MAX(x,y) (x = y)
? x : y;
/home/leif/apache/trafficserver.git/iocore/net/P_InkBulkIO.h: #define MAX(x,
y) (x y ? x : y)
loki (10:48) 893/0 $ tsg 'MIN\(' | grep define
/home/leif/apache/trafficserver.git/proxy/http/HttpTunnel.cc: #define
MIN(x,y) ((x) = (y)) ? (x) : (y);
/home/leif/apache/trafficserver.git/proxy/PluginVC.cc: #define MIN(x,y) (((x)
= (y)) ? (x) : (y))
/home/leif/apache/trafficserver.git/proxy/InkAPITestTool.cc: #define MIN(_x,
_y) ((_x _y) ? _x : _y)
/home/leif/apache/trafficserver.git/proxy/MuxVC.cc: #define MIN(x,y) (x = y)
? x : y;
/home/leif/apache/trafficserver.git/example/thread-pool/psi.c: #define
MIN(x,y) ((x y) ? x :y)
/home/leif/apache/trafficserver.git/iocore/net/NetVCTest.cc: #define MIN(x,y)
(x = y) ? x : y;
{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-1771) add http_load to the build
[ https://issues.apache.org/jira/browse/TS-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618921#comment-13618921 ] ASF subversion and git services commented on TS-1771: - Commit 4aa69fb3514ac197c94c1b8419b0a862dd57e18d in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4aa69fb ] TS-1771: add http_load to the build add http_load to the build -- Key: TS-1771 URL: https://issues.apache.org/jira/browse/TS-1771 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Fix For: 3.3.2 We should add http_load to the build so that it's easy for devs to use it for performance testing. -- 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-1660) Host field should not has c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618934#comment-13618934 ] Leif Hedstrom commented on TS-1660: --- weijin: Looking at this code, can you explain to me how the \0 sneaks in there ? If it's from client / user input, shouldn't the validation happen when we read / parse the request ? I.e. how would we get a '\0' into the Host: in the first place ? Host field should not has c style terminator - Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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-1766) resurrect unit test programs
[ https://issues.apache.org/jira/browse/TS-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618936#comment-13618936 ] ASF subversion and git services commented on TS-1766: - Commit 3116860ed11f52a4fa7b38037caece9f39262a36 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3116860 ] TS-1766: integrate AIO test into the autotools test suite - Add some const to Diags tags API. - Use _SOURCES rather than _LDADD to build source files. - Remove unused macro MGMT_PTR. - Remove ProcessManager usage of global_config_cbs global to reduce the number of global dependencies. - Add AIO unit test to the build. - Move AIO tests into a single file. resurrect unit test programs Key: TS-1766 URL: https://issues.apache.org/jira/browse/TS-1766 Project: Traffic Server Issue Type: Bug Components: Cleanup, Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.4 There are a lot of test source files in the source tree that are never built into actual test programs. We should build these into standalone test programs so that make check runs them as unit tests. -- 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-1771) add http_load to the build
[ https://issues.apache.org/jira/browse/TS-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618940#comment-13618940 ] ASF subversion and git services commented on TS-1771: - Commit c9647a95c56043bedc819fdac8fd0bf89ca67b04 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c9647a9 ] Update CHANGES for TS-1771 add http_load to the build -- Key: TS-1771 URL: https://issues.apache.org/jira/browse/TS-1771 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: James Peach Fix For: 3.3.2 We should add http_load to the build so that it's easy for devs to use it for performance testing. -- 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-1794) Eliminate ink_debug_assert() and use ink_assert() consistently.
[
https://issues.apache.org/jira/browse/TS-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1794:
--
Fix Version/s: 3.3.2
Assignee: Leif Hedstrom
Eliminate ink_debug_assert() and use ink_assert() consistently.
---
Key: TS-1794
URL: https://issues.apache.org/jira/browse/TS-1794
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.2
Seems odd and unreasonable to have both. I think we should have two asserts
only:
{code}
ink_assert()
ink_release_assert()
{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] [Created] (TS-1794) Eliminate ink_debug_assert() and use ink_assert() consistently.
Leif Hedstrom created TS-1794:
-
Summary: Eliminate ink_debug_assert() and use ink_assert()
consistently.
Key: TS-1794
URL: https://issues.apache.org/jira/browse/TS-1794
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Seems odd and unreasonable to have both. I think we should have two asserts
only:
{code}
ink_assert()
ink_release_assert()
{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-1772) Remove multiple TS_INLINE defines
[ https://issues.apache.org/jira/browse/TS-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1772: Summary: Remove multiple TS_INLINE defines (was: remove Inline.cc files) OK, I'm really on crack here. The Inline.cc files are there so that there is an extern definition for places that don't see the inline definition or can't use it. There's still scope here to remove the multiple TS_INLINE definitions though, so let's do that. Remove multiple TS_INLINE defines - Key: TS-1772 URL: https://issues.apache.org/jira/browse/TS-1772 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: James Peach Fix For: 3.3.2 The use of Inline.cc files was probably related to old compilers not inlining things correctly, or possibly some code bloat issues. Right now they are just confusing and cluttering up the build system; let's remove them. -- 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-1772) Remove multiple TS_INLINE defines
[ https://issues.apache.org/jira/browse/TS-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619015#comment-13619015 ] ASF subversion and git services commented on TS-1772: - Commit 7ca19476f5e0b52f9d65cb11df051c045b832542 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7ca1947 ] TS-1772: Remove multiple TS_INLINE defines It took me a couple of tries to understand what the Inline.cc files were for, but it's actually not necessary for TS_INLINE to be defined in many different places. All we need to do to get correct inlining is define an extern version, and make an inline version available in a header. Forward declarations should be extern, not TS_INLINE. Remove multiple TS_INLINE defines - Key: TS-1772 URL: https://issues.apache.org/jira/browse/TS-1772 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: James Peach Fix For: 3.3.2 The use of Inline.cc files was probably related to old compilers not inlining things correctly, or possibly some code bloat issues. Right now they are just confusing and cluttering up the build system; let's remove them. -- 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-1760) use linux native aio
[ https://issues.apache.org/jira/browse/TS-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619022#comment-13619022 ] James Peach commented on TS-1760: - I added the AIO unit tests to the build. They might be helpful in validating this change. It would be great to add more AIO test scripts. use linux native aio Key: TS-1760 URL: https://issues.apache.org/jira/browse/TS-1760 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: weijin Assignee: weijin Fix For: 3.3.2 Attachments: native_aio.patch add a feature that use linux native aio -- 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] [Closed] (TS-1764) Unify definitions of MAX() and MIN()
[
https://issues.apache.org/jira/browse/TS-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach closed TS-1764.
---
Resolution: Fixed
Unify definitions of MAX() and MIN()
Key: TS-1764
URL: https://issues.apache.org/jira/browse/TS-1764
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 3.3.2
There are a few duplications of these definitions, this would be splendid to
unify into one definition for each (yes amc, I know there's std::max :-).
{code}
loki (10:48) 892/0 $ tsg 'MAX\(' | grep define
/home/leif/apache/trafficserver.git/proxy/PluginVC.cc: #define MAX(x,y) (((x)
= (y)) ? (x) : (y))
/home/leif/apache/trafficserver.git/proxy/MuxVC.cc: #define MAX(x,y) (x = y)
? x : y;
/home/leif/apache/trafficserver.git/iocore/net/P_InkBulkIO.h: #define MAX(x,
y) (x y ? x : y)
loki (10:48) 893/0 $ tsg 'MIN\(' | grep define
/home/leif/apache/trafficserver.git/proxy/http/HttpTunnel.cc: #define
MIN(x,y) ((x) = (y)) ? (x) : (y);
/home/leif/apache/trafficserver.git/proxy/PluginVC.cc: #define MIN(x,y) (((x)
= (y)) ? (x) : (y))
/home/leif/apache/trafficserver.git/proxy/InkAPITestTool.cc: #define MIN(_x,
_y) ((_x _y) ? _x : _y)
/home/leif/apache/trafficserver.git/proxy/MuxVC.cc: #define MIN(x,y) (x = y)
? x : y;
/home/leif/apache/trafficserver.git/example/thread-pool/psi.c: #define
MIN(x,y) ((x y) ? x :y)
/home/leif/apache/trafficserver.git/iocore/net/NetVCTest.cc: #define MIN(x,y)
(x = y) ? x : y;
{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-1631) Clear Stats doesn't work - old value return
[ https://issues.apache.org/jira/browse/TS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619102#comment-13619102 ] ASF subversion and git services commented on TS-1631: - Commit 78197f392ed6514f9de5b6738b39481c169e75fe in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=78197f3 ] Added TS-1631. Clear Stats doesn't work - old value return --- Key: TS-1631 URL: https://issues.apache.org/jira/browse/TS-1631 Project: Traffic Server Issue Type: Bug Components: Management API, Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: clear_stats_ver_1.diff, clear_stats_ver_2.diff, clear_stats_ver_3.diff I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. -- 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-1631) Clear Stats doesn't work - old value return
[ https://issues.apache.org/jira/browse/TS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619103#comment-13619103 ] ASF subversion and git services commented on TS-1631: - Commit 850ca412deb9bd0a477c5ac1f43e15bafaa425c8 in branch refs/heads/master from [~kopely] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=850ca41 ] TS-1631 Mgmt API to clear stats does not actually clear it Review and minor mods: Leif. Clear Stats doesn't work - old value return --- Key: TS-1631 URL: https://issues.apache.org/jira/browse/TS-1631 Project: Traffic Server Issue Type: Bug Components: Management API, Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: clear_stats_ver_1.diff, clear_stats_ver_2.diff, clear_stats_ver_3.diff I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. -- 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-1789) Script to compare RecordsConfig.cc default values with records.config.default.in
[ https://issues.apache.org/jira/browse/TS-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619170#comment-13619170 ] ASF subversion and git services commented on TS-1789: - Commit 0af1d8acc14dd7dc4bd123ada941482b0c74e7b7 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0af1d8a ] Added TS-1789. Script to compare RecordsConfig.cc default values with records.config.default.in Key: TS-1789 URL: https://issues.apache.org/jira/browse/TS-1789 Project: Traffic Server Issue Type: Test Components: Management Reporter: Mark Harrison Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: compare_RecordsConfigcc.py zwoop it'd also be nice to have a script that verifies that what we have in records.config.default.in has the same defaults as in mgmt/RecordsConfig.cc -- 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-1789) Script to compare RecordsConfig.cc default values with records.config.default.in
[ https://issues.apache.org/jira/browse/TS-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619171#comment-13619171 ] ASF subversion and git services commented on TS-1789: - Commit 8fdd369b59d42bd487f212ffafaf0876a6941251 in branch refs/heads/master from [~a...@brivo.com] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8fdd369 ] TS-1789 Script to compare RecordsConfig.cc default values with records.config.default.in Script to compare RecordsConfig.cc default values with records.config.default.in Key: TS-1789 URL: https://issues.apache.org/jira/browse/TS-1789 Project: Traffic Server Issue Type: Test Components: Management Reporter: Mark Harrison Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: compare_RecordsConfigcc.py zwoop it'd also be nice to have a script that verifies that what we have in records.config.default.in has the same defaults as in mgmt/RecordsConfig.cc -- 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-1795) check that records.config stays in sync
James Peach created TS-1795: --- Summary: check that records.config stays in sync Key: TS-1795 URL: https://issues.apache.org/jira/browse/TS-1795 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach We should integrate the script from TS-1789 into the build and make sure that records.config never gets stale. -- 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-1736) Fatal() terminate process without logging backtrace
[ https://issues.apache.org/jira/browse/TS-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619285#comment-13619285 ] James Peach commented on TS-1736: - I don't much like this patch; there is a problem with LocalManager::mgmtShutdown() clobberring status with waitpid() and I think the notion of this function calling exit() is flawed. It seems to me that there is only 1 place that needs to call _exit() and that is the call from mgmt/Main.cc. Can we remove the _exit() form mgmtShutdown() and just call it in the one place it's needed? If you do that, you should also be able to remove the status argument from mgmtShutdown(). Fatal() terminate process without logging backtrace --- Key: TS-1736 URL: https://issues.apache.org/jira/browse/TS-1736 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Yunkai Zhang Assignee: James Peach Fix For: 3.3.2 Attachments: 0001-diags-Fatal-terminate-process-without-logging-backtr-V2.patch The root casue is that cleanup_func() was called before logging backtrace in Diags::error(), however cleanup_func() would terminate process by calling exit() directly. -- 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-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619289#comment-13619289
]
Leif Hedstrom commented on TS-1053:
---
Ping ?
get combo_handler compiled
--
Key: TS-1053
URL: https://issues.apache.org/jira/browse/TS-1053
Project: Traffic Server
Issue Type: Task
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.2
Attachments: combo_handler.diff, fetcher.diff, Makefile
combo_handler require ESI's code. Before make ESI work as a lib, you can try
it this way:
make esi/lib and esi/fetcher the subdir of combo_handler and use the
makefile.
{noformat}
combo_handler
|combo_handler.cc
|fetcher
|lib
|LICENSE
|Makefile
|README
{noformat}
--
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-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1053:
--
Fix Version/s: (was: 3.3.2)
3.3.4
get combo_handler compiled
--
Key: TS-1053
URL: https://issues.apache.org/jira/browse/TS-1053
Project: Traffic Server
Issue Type: Task
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.4
Attachments: combo_handler.diff, fetcher.diff, Makefile
combo_handler require ESI's code. Before make ESI work as a lib, you can try
it this way:
make esi/lib and esi/fetcher the subdir of combo_handler and use the
makefile.
{noformat}
combo_handler
|combo_handler.cc
|fetcher
|lib
|LICENSE
|Makefile
|README
{noformat}
--
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-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619309#comment-13619309 ] ASF subversion and git services commented on TS-1632: - Commit 727fbf717e2eee6becdcdd1c675d5218074d1536 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=727fbf7 ] Added TS-1632. RecDecrRawStat does not seem to work as intended Key: TS-1632 URL: https://issues.apache.org/jira/browse/TS-1632 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? -- 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-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619310#comment-13619310 ] ASF subversion and git services commented on TS-1632: - Commit 76e5a90b45359e10d68ce99abe64ea016873597f in branch refs/heads/master from [~kopely] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=76e5a90 ] TS-1632 RecDecrRawStat does not seem to work as intended Note that part of this was committed in TS-1674. But I think the additional safety checks from the v2 patch makes sense. RecDecrRawStat does not seem to work as intended Key: TS-1632 URL: https://issues.apache.org/jira/browse/TS-1632 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.2 Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? -- 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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619345#comment-13619345 ] James Peach commented on TS-1405: - I started trying to review this. It would be really helpful to have some comments around PriorityEventQueue, particularly the various constants. I'll spend more time on this tomorrow; maybe it will become clearer as I read more ;) apply time-wheel scheduler about event system -- Key: TS-1405 URL: https://issues.apache.org/jira/browse/TS-1405 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, linux_time_wheel_v9jp.patch when have more and more event in event system scheduler, it's worse. This is the reason why we use inactivecop to handler keepalive. the new scheduler is time-wheel. It's have better time complexity(O(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-1736) Fatal() terminate process without logging backtrace
[ https://issues.apache.org/jira/browse/TS-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619454#comment-13619454 ] Yunkai Zhang commented on TS-1736: -- Oh, I hadn't noticed the status mistake, thank you. Agree to you, Let's remove the status argument, and call _exit() after this function when necessary. I'll give V3. Fatal() terminate process without logging backtrace --- Key: TS-1736 URL: https://issues.apache.org/jira/browse/TS-1736 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Yunkai Zhang Assignee: James Peach Fix For: 3.3.2 Attachments: 0001-diags-Fatal-terminate-process-without-logging-backtr-V2.patch The root casue is that cleanup_func() was called before logging backtrace in Diags::error(), however cleanup_func() would terminate process by calling exit() directly. -- 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-1793) force cluster connection = cluster number for cluster thread balance
[ https://issues.apache.org/jira/browse/TS-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619464#comment-13619464 ] ASF subversion and git services commented on TS-1793: - Commit c4b7b61d0852bf67d87a48335b271135c3aa027e in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c4b7b61 ] TS-1793 force cluster connection = cluster number for cluster thread balance force cluster connection = cluster number for cluster thread balance - Key: TS-1793 URL: https://issues.apache.org/jira/browse/TS-1793 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Attachments: TS-1793.patch force cluster connection = cluster number for cluster thread balance. The TS-1751 will base on this issue -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
Bin Chen created TS-1796: Summary: remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen -- 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] [Assigned] (TS-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1796: Assignee: Bin Chen remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number -- Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen -- 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-1736) Fatal() terminate process without logging backtrace
[ https://issues.apache.org/jira/browse/TS-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1736: - Attachment: 0001-diags-Fatal-terminate-process-without-logging-backtr-V3.patch Fatal() terminate process without logging backtrace --- Key: TS-1736 URL: https://issues.apache.org/jira/browse/TS-1736 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Yunkai Zhang Assignee: James Peach Fix For: 3.3.2 Attachments: 0001-diags-Fatal-terminate-process-without-logging-backtr-V2.patch, 0001-diags-Fatal-terminate-process-without-logging-backtr-V3.patch The root casue is that cleanup_func() was called before logging backtrace in Diags::error(), however cleanup_func() would terminate process by calling exit() directly. -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1796: - Attachment: TS-1796.patch remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number -- Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Attachments: TS-1796.patch -- 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-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619471#comment-13619471 ] ASF subversion and git services commented on TS-1713: - Commit 457b231b6c6c3f53c7c7e5264460c2dc3ad8f9d5 in branch refs/heads/master from Zhao Yongming ming@gmail.com [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=457b231 ] TS-1713: SRV support refine the currenty SRV supporting in the DNS is not complete, and here is a full refine of the old codes, as a side affect we also bump the HostDB database version to 3.0, and increase the disk spaces from 32MB to 200MB: CONFIG proxy.config.hostdb.storage_size INT 200M ***CAUTION** YOU ARE WARNED THAT FAIL TO ADJUST THE hostdb.storage_size CAN NOT START THE SERVER PROCESS PROPERLY!! Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- 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-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619474#comment-13619474 ] James Peach commented on TS-1713: - Please add any upgrading and compatibility notes to the wiki https://cwiki.apache.org/confluence/display/TS/Upgrading+Traffic+Server thanks! Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1796: Fix Version/s: 3.3.2 remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number -- Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1796.patch -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619479#comment-13619479 ] ASF subversion and git services commented on TS-1796: - Commit 366fab2ae35510fee9d2182edc7be4ea44c3ebab in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=366fab2 ] TS-1796 remove cluster connection number change handle remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number -- Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1796.patch -- 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] [Closed] (TS-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1796. Resolution: Fixed remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number -- Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1796.patch -- 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-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1751: - Fix Version/s: (was: 3.5.0) 3.3.2 when ts have high cpu usage, cluster thread isn't balance - Key: TS-1751 URL: https://issues.apache.org/jira/browse/TS-1751 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1751.patch, TS-1751_v2.patch eg: 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] -- 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-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1751: - Attachment: TS-1751_v3.patch when cluster connection assigned ok(origin assign by connection handle), don't bind clear and bind. when ts have high cpu usage, cluster thread isn't balance - Key: TS-1751 URL: https://issues.apache.org/jira/browse/TS-1751 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1751.patch, TS-1751_v2.patch, TS-1751_v3.patch eg: 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] -- 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-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619490#comment-13619490 ] ASF subversion and git services commented on TS-1713: - Commit 3050ce9bdfe65016b93d26d213d76cf39d46e804 in branch refs/heads/master from weijin taorui...@taobao.com [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3050ce9 ] TS-1713 just make ts can build on clang Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- 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-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619493#comment-13619493 ] Leif Hedstrom commented on TS-1713: --- Ouch, really?? 200MB?? Most people will use ATS in reverse proxy mode, why do we need 200MB hostDB? This makes no sense, please explain, and/or revert. Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- 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-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619496#comment-13619496 ] Leif Hedstrom commented on TS-1713: --- In fact, unless you can give some reasonable explanation why we need a 200MB HostDB as the default, I'm definitely -1 on this. Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- 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-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619534#comment-13619534 ] ASF subversion and git services commented on TS-1751: - Commit 7b2bc024aace7515c9638063a9c434da40b80799 in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7b2bc02 ] TS-1751 when ts have high cpu usage, cluster thread isn't balance when ts have high cpu usage, cluster thread isn't balance - Key: TS-1751 URL: https://issues.apache.org/jira/browse/TS-1751 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1751.patch, TS-1751_v2.patch, TS-1751_v3.patch eg: 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] -- 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] [Closed] (TS-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1751. Resolution: Fixed when ts have high cpu usage, cluster thread isn't balance - Key: TS-1751 URL: https://issues.apache.org/jira/browse/TS-1751 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1751.patch, TS-1751_v2.patch, TS-1751_v3.patch eg: 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] -- 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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619536#comment-13619536 ] Bin Chen commented on TS-1405: -- yeah, i should read more carefully. But i can test this patch first. Thanks John. apply time-wheel scheduler about event system -- Key: TS-1405 URL: https://issues.apache.org/jira/browse/TS-1405 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, linux_time_wheel_v9jp.patch when have more and more event in event system scheduler, it's worse. This is the reason why we use inactivecop to handler keepalive. the new scheduler is time-wheel. It's have better time complexity(O(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
