ATS versions - 6.2.1 Cache disk - 18G ramdisk - /dev/ram0 Storage.config configured to use 14G of ramdisk System memory - 32G Traffic type - HLS Live Connections - sustained 4k Trafffic - 5-6gbps Hit ratio - 97%
So it looks like I misread/misinterpreted a few things during testing referenced in my previous email. It looks like my issue was never run away memory using ramdisk, it looks like something internal to ATS that I can't seem to isolate. Since I am not seeing this type of memory consumption with my large-file/VOD cache servers, and the connection profile is much different, I am guessing what may be at issue is the long living connections. ATS active timeout is currently set to 3600. This is live traffic so connections stay open for a hour and then closed. Where as with my large-file/VOD cache servers, connections only remain open for as long as a file/title is being retrieved. 10-15mins max. Has anyone seen any issues with this type of connection profile and ATS 6.2.1? This doesnt seem to be an issue with 7.0, so not sure what may have changed between releases. Thanks! On Tue, Jun 6, 2017 at 8:32 AM, Jeremy Payne <[email protected]> wrote: > ATS versions - 6.2.1 and 7.0.0 > Cache disk - 18G ramdisk - /dev/ram0 > System memory - 32G > Traffic type - HLS Live > > While testing live HLS traffic, I noticed that ATS 6.2.1. continued to use > ramdisk until > eventually traffic_server was restarted(via trafic_cop) as result of 'oom > killer' > > Testing with ATS 7.0.0 I saw memory use remain stable once the ramdisk > reached it's > 'configured' capacity. > > I looked through the 7.0 changelog and didnt see anything obvious, so > maybe someone is aware of an undocumented change which impacts ATS > 'honoring' configured ramdisk boundaries. > Understood ATS may not know the difference between /dev/sdX and > /dev/ramX.. But just > putting this out to the community just in case I am missing something. > > Jeremy > > > > > >
