[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=13539224#comment-13539224 ] jaekyung oh commented on TS-1006: - i've tried again in accordance with your guide. [2ba8ae8cc700:43][ink_queue.cc:00601][-] all:4011MB t:1024f:8 m:40 avg:40.0malloc:1016csize:32tsize:32768 cbsize:1052672 [2ba8adbb7e20:40][ink_queue.cc:00595][M] all:4029MB t:767 f:87m:86 avg:84.8malloc:680 csize:64tsize:4096cbsize:266240 [2ba8adbb7e20:40][ink_queue.cc:00601][-] all:4029MB t:703 f:23m:86 avg:84.8malloc:680 csize:64tsize:4096cbsize:266240 [2ba8ae8cc700:03][ink_queue.cc:00668][F] all:4044MB t:628 f:108 m:108 avg:107.1 malloc:519 csize:70tsize:232 cbsize:16384 [2ba8ae8cc700:03][ink_queue.cc:00674][-] all:4044MB t:557 f:38m:108 avg:107.1 malloc:519 csize:70tsize:232 cbsize:16384 /usr/local/bin/traffic_server - STACK TRACE: /usr/local/lib/libtsutil.so.3(ink_freelist_new+0x992)[0x2ba8ab4b5072] /usr/local/bin/traffic_server[0x64a68f] /usr/local/bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x1e2)[0x64ef52] /usr/local/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x754)[0x67ef54] /usr/local/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x130)[0x6540f0] /usr/local/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x74)[0x521c14] /usr/local/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xfd)[0x538c1d] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb20)[0x54ffd0] /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x33a)[0x547fda] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x353)[0x5494d3] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x538)[0x54f9e8] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb92)[0x550042] /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x33a)[0x547fda] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x353)[0x5494d3] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x538)[0x54f9e8] /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x33a)[0x547fda] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x353)[0x5494d3] /usr/local/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x9a)[0x55091a] /usr/local/bin/traffic_server(TSHttpTxnReenable+0x40d)[0x4bec1d] /usr/local/libexec/trafficserver/purge.so(+0x1e56)[0x2ba8b99bfe56] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0xfb)[0x54927b] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x538)[0x54f9e8] /usr/local/bin/traffic_server(_ZN6HttpSM32setup_client_read_request_headerEv+0x39f)[0x54793f] /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x25a)[0x547efa] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x353)[0x5494d3] /usr/local/bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x688)[0x54a4e8] /usr/local/bin/traffic_server(_ZN17HttpClientSession16state_keep_aliveEiPv+0xa8)[0x523738] /usr/local/bin/traffic_server[0x6b6f4a] /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1fe)[0x6aff0e] /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8e)[0x6dfd4e] /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4f0)[0x6e06c0] /usr/local/bin/traffic_server[0x6df9b2] /lib64/libpthread.so.0(+0x6a3f)[0x2ba8ab6dca3f] /lib64/libc.so.6(clone+0x6d)[0x2ba8ad91a67d] FATAL: Failed to mmap 50331648 bytes, Cannot allocate memory - here you want? /usr/local/bin/traffic_server - STACK TRACE: /usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2ba8ab4b0c68] /usr/local/lib/libtsutil.so.3(+0x17aca)[0x2ba8ab4b3aca] /usr/local/lib/libtsutil.so.3(ink_freelist_new+0x992)[0x2ba8ab4b5072] /usr/local/bin/traffic_server[0x64a68f] /usr/local/bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x1e2)[0x64ef52] 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,
[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=13539229#comment-13539229
]
Yunkai Zhang commented on TS-1006:
--
Ok, thanks.
I'll give a patch later, It'll do some optimization - Merge a data
struct(InkChunkInfo) into chunk to reduce memory fragment. I'm not sure it will
fix this issue, but worth trying.
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 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
[jira] [Commented] (TS-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539306#comment-13539306
]
James Peach commented on TS-1528:
-
AFAICT there is no 4G limit. The only thing I found was a format string bug.
Unless there's a reproducible problem, we should leave this closed.
ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
---
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
Assignee: Zhao Yongming
Fix For: 3.3.3
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested
attaching some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{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-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-1006:
-
Attachment: 0003-Allocator-store-InkChunkInfo-into-Chunk.patch
Instead of allocating InkChunkInfo by ats_memalign(), store it
into chunk, it can reduce memory fragment a bit.
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,
0003-Allocator-store-InkChunkInfo-into-Chunk.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 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |
[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=13539313#comment-13539313
]
Yunkai Zhang commented on TS-1006:
--
[~genext]
Please try this patch: 0003-Allocator-store-InkChunkInfo-into-Chunk.patch, and
give us some feedback.
Just apply it upon 0001-0002 patches.
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,
0003-Allocator-store-InkChunkInfo-into-Chunk.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 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 |
[jira] [Resolved] (TS-1246) trafficserver script error message (in ubuntu)
[
https://issues.apache.org/jira/browse/TS-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-1246.
-
Resolution: Fixed
Assignee: James Peach
aac493996e62ef018bd13887d75e249541dfa7be TS-1246: trafficserver script error
message in ubuntu
It seems like there's a lot going on in this ticket, but it's pretty old and
only the rc script issue seemed soluble. So I fixed that. If there's any other
issues to solve here, please file a new ticket. Thanks.
trafficserver script error message (in ubuntu)
--
Key: TS-1246
URL: https://issues.apache.org/jira/browse/TS-1246
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.0.4
Environment: OS : Linux 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5
21:13:25 UTC 2012 x86_64 GNU/Linux
trafficserver 3.04 (also 3.02)
Reporter: JH Kim
Assignee: James Peach
Priority: Minor
Fix For: 3.3.1
1. /usr/local/bin/trafficserver stop
error message appeared in traffic.out below
[TrafficManager] == Cleaning up and reissuing signal #3
[May 4 16:52:50.177] Manager {140461686372128} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #3
[May 4 16:52:50.177] Manager {140461686372128} ERROR: (last system error 2:
No such file or directory)
2. /usr/local/bin/trafficserver restart
error message appeared in traffic.out below
[TrafficManager] == Cleaning up and reissuing signal #3
[May 4 17:56:59.306] Manager {139910575142688} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #3
[May 4 17:56:59.306] Manager {139910575142688} ERROR: (last system error 2:
No such file or directory)
FATAL == [ProcessManager::pollLMConnection] Lost Manager EOF![E. Mgmt] :
Interrupted system call
Is it okay?
OS : Linux 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64
GNU/Linux
trafficserver 3.04 (also 3.02)
--
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
