trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Call <bc...@apache.org>
Subject Re: Ramdisk - 6.2.1 vs 7.0.0
Date Fri, 09 Jun 2017 16:02:18 GMT
What is your proxy.config.net.default_inactivity_timeout set to?  You can also do a dump of
the memory by doing:

$ sudo kill -SIGUSR1 $(pidof traffic_server). # and look at traffic.out.

That will give a pretty good idea on where the memory is being used.

-Bryan

> On Jun 8, 2017, at 3:35 PM, Jeremy Payne <jp557198@gmail.com> wrote:
> 
> 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 <jp557198@gmail.com <mailto:jp557198@gmail.com>>
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
> 
> 
> 
>  
> 
> 


Mime
View raw message