dhairav commented on issue #9625: URL: https://github.com/apache/trafficserver/issues/9625#issuecomment-1522127545
First of all, thanks for your time on this, highly appreciated. I was able to get the output of the Memory allocations of the process using the SIGUSR1 command - and the results were surprising, and just like the ones posted here - https://www.mail-archive.com/[email protected]/msg15718.html. Our in-use memory output from the traffic report shows north of 90GB RAM allocation just to the `memory/ioBufAllocator`. ` Allocated | In-Use | Type Size | Free List Name --------------------|--------------------|------------|---------------------------------- 2818572288 | 2518679552 | 2097152 | memory/ioBufAllocator[14] 75094818816 | 72394735616 | 1048576 | memory/ioBufAllocator[13] 17850957824 | 14342422528 | 524288 | memory/ioBufAllocator[12] 2743074816 | 2159017984 | 262144 | memory/ioBufAllocator[11] 6836715520 | 5769527296 | 131072 | memory/ioBufAllocator[10] 1214251008 | 562626560 | 65536 | memory/ioBufAllocator[9] 1529872384 | 675119104 | 32768 | memory/ioBufAllocator[8] 232259584 | 215384064 | 16384 | memory/ioBufAllocator[7] 148111360 | 116465664 | 8192 | memory/ioBufAllocator[6] 25165824 | 18317312 | 4096 | memory/ioBufAllocator[5] 262144 | 0 | 2048 | memory/ioBufAllocator[4] 131072 | 0 | 1024 | memory/ioBufAllocator[3] 65536 | 3584 | 512 | memory/ioBufAllocator[2] 26247168 | 26214400 | 256 | memory/ioBufAllocator[1] 16384 | 2432 | 128 | memory/ioBufAllocator[0] 122880 | 85728 | 96 | memory/eventAllocator 244800 | 151520 | 80 | memory/mutexAllocator 385024 | 233600 | 64 | memory/ioBlockAllocator 16401600 | 15257184 | 48 | memory/ioDataAllocator 620160 | 614400 | 240 | memory/ioAllocator 0 | 0 | 432 | memory/socksAllocator 0 | 0 | 128 | memory/udpReadContAllocator 0 | 0 | 160 | memory/udpPacketAllocator 110592 | 35424 | 864 | memory/netVCAllocator 0 | 0 | 128 | memory/UDPIOEventAllocator 2490368 | 1377280 | 1024 | memory/sslNetVCAllocator 15400960 | 13600128 | 64 | memory/RamCacheLRUEntry 0 | 0 | 96 | memory/RamCacheCLFUSEntry 614400 | 601760 | 160 | memory/openDirEntry 0 | 0 | 48 | memory/evacuationKey 8192 | 0 | 64 | memory/cacheRemoveCont 36864 | 29664 | 96 | memory/evacuationBlock 3681600 | 3571152 | 944 | memory/cacheVConnection 0 | 0 | 16 | memory/DNSRequestDataAllocator 118336 | 29584 | 29584 | memory/dnsBufAllocator 163840 | 0 | 1280 | memory/dnsEntryAllocator 4096 | 384 | 16 | memory/expiryQueueEntry 8192 | 1536 | 64 | memory/refCountCacheHashingValueAllocator 0 | 0 | 96 | memory/hostDBFileContAllocator 1179648 | 4608 | 2304 | memory/hostDBContAllocator 0 | 0 | 128 | memory/OneWayTunnelAllocator 13369344 | 11757568 | 2048 | memory/hdrStrHeap 14155776 | 12154880 | 2048 | memory/hdrHeap 32768 | 1024 | 256 | memory/httpCacheAltAllocator 0 | 0 | 3088 | memory/http2StreamAllocator 0 | 0 | 3440 | memory/http2ClientSessionAllocator 0 | 0 | 128 | memory/RemapPluginsAlloc 122880 | 98880 | 192 | memory/httpServerSessionAllocator 4546560 | 301920 | 8880 | memory/httpSMAllocator 2088960 | 2040000 | 960 | memory/http1ClientSessionAllocator 0 | 0 | 128 | memory/socksProxyAllocator 5676130304 | 5676128064 | 32 | memory/MIMEFieldSDKHandle 36864 | 0 | 288 | memory/INKVConnAllocator 81920 | 9088 | 128 | memory/INKContAllocator 40960 | 4736 | 32 | memory/apiHookAllocator 0 | 0 | 512 | memory/FetchSMAllocator 524288 | 33792 | 1024 | memory/ArenaBlock 114273243904 | 104536640000 | | TOTAL ----------------------------------------------------------------------------------------- ` Is our only option running ATS with freelist disabled? If so, would there be any performance implications due to the same? Of-course we will performance test this, but anything specifically to look into would be helpful here. Also, as per the documentation - it has two options for disabling freelist: -F and -f, are they to be used in conjunction with each other? or simply a -F or a -f individually would do? If we are indeed disabling freelist, would you prefer us to then replace it with Jemalloc using the proxy binary options you have mentioned above? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
