[jira] [Created] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as

2011-12-22 Thread Alistair Stevenson (Created) (JIRA)
TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int 
*bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter needs 
to be removed as it is not used.
-

 Key: TS-1061
 URL: https://issues.apache.org/jira/browse/TS-1061
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.0.1, 3.1.1
 Environment: Redhat Linux but it is not environment specific
Reporter: Alistair Stevenson
Priority: Minor
 Fix For: 3.1.1


The definitions are:

./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
txnp);

The int * bytes parameter is not used and means that the function does not 
resolve and so cannot be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TS-1006) memory management, cut down memory waste ?

2011-12-22 Thread Zhao Yongming (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175301#comment-13175301
 ] 

Zhao Yongming commented on TS-1006:
---

the memory waste in TS is mostly because the Ramcache:
1, it is counted by really used memory.
2, it will hold the whole block of memory from free to OS, the old glibc memory 
management issue.
3, ramcache use the cache reader buffer, and the buffer is allocated from 
anywhere in the whole memory adress

all those make TS waste much more memory than Ramcache is configured. it will 
eat all you memory at then end.

what we want to do:
1, limit ramcache memory by allocator
2, bound ram lur list and freelist
3, freelist will be split by size
4, split ramcache memory and cache memory

the codes will be ready in days

 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: Zhao Yongming
 Fix For: 3.1.3

 Attachments: 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