Yea for the disable feature that is meant to be on a per volume basis. The general idea being if you had a bunch of ram disks you would have them organized into a specific volume, and you would send data there that does not need to be long lived but benefits from caching (think something like live video). In that instance you could disable the ram cache via the flag in the volume config for your ramdisk volume. Meanwhile leave the ramcache enabled for physical disks that would be on their volume(s) and benefit from a real ramcache. However if you are only running with ramdisks for storage then just disabling the ramcache all together via the size value probably makes more sense then having to do volume organization.
On Wed, Apr 7, 2021 at 9:59 PM Miles Libbey <[email protected]> wrote: > And to add a bit more context: > - The RAM Cache is highly related to the Disk Cache and physical disks -- > as you surmise, the disk cache would need to be at least as big as the RAM > cache. > - BUT, as Kit and Rob mention, RAM Disks are a neat cheat -- ATS thinks of > them as a disk cache. If you are exclusively running with RAM Disks, you > should likely set proxy.config.cache.ram_cache.size (in records.config) to > nil ( > https://docs.trafficserver.apache.org/en/8.1.x/admin-guide/files/records.config.en.html#proxy-config-cache-ram-cache-size). > I believe the feature Kit refers to is new in ATS 9, and is more focused on > the mixed case (for instance, we run both RAM Disk and physical disks -- > the RAM Cache associated with the RAM disk unnecessarily wastes memory). > miles > > On Wed, Apr 7, 2021 at 12:24 PM Shu Kit Chan <[email protected]> wrote: > >> I also used RAM disk as well. And one thing I will try is to disable the >> ram cache of ATS - >> https://docs.trafficserver.apache.org/en/latest/admin-guide/storage/index.en.html#disabling-the-ram-cache >> >> >> I think that will then make it a bit more straightforward to reason about >> the whole situation. >> >> Kit >> >> On Wed, Apr 7, 2021 at 10:04 AM Nick Dunkin <[email protected]> >> wrote: >> >>> Hi Rob, >>> >>> >>> >>> This is excellent information, thank you very much. >>> >>> >>> >>> I had considered a large RAM cache setting (ram_cache) with just a small >>> disk cache, but the ATS documentation was very vague about what this would >>> mean. The documentation refers to the ram cache as a place where popular >>> items are *promoted*, inferring (to me at least) that the size of the >>> disk cash would always have to be larger than the ram cache, in order make >>> full use of the ram cache. >>> >>> >>> >>> As you say though, I prefer the RAM disk path. >>> >>> >>> >>> Thanks again, >>> >>> >>> >>> Nick >>> >>> >>> >>> *From: *Robert O Butts <[email protected]> >>> *Reply-To: *"[email protected]" < >>> [email protected]> >>> *Date: *Wednesday, April 7, 2021 at 12:54 PM >>> *To: *"[email protected]" <[email protected]> >>> *Subject: *Re: RAM disks for cache? >>> >>> >>> >>> Yes, we have some similar servers in Production. We use ramdisks, it >>> works fine. You could also theoretically give ATS a large memory cache and >>> small disk (proxy.config.cache.ram_cache.size). But then that cache is >>> shared across all remaps, and you lose the control of different volumes for >>> different domains, and ATS just generally isn't really designed for that. >>> We've found ramdisks to work better in practice. >>> >>> I will note, our servers like this also have poor CPUs. We thought this >>> would be ok when we bought them, but it turns out you really kind of need >>> decent CPU for things like SSL, and poor CPUs also tend to have poor PCI >>> lanes, which are important. Our servers like this tend to cap out around >>> 10Gbps, despite +20Gbps NICs. I don't know if yours are similar, but if >>> your memory-poor servers are also CPU-poor, you might have the same >>> bottlenecks. And that's not ATS' fault, it seems unlikely any other caching >>> proxy could do better. >>> >>> >>> >>> >>> >>> On Wed, Apr 7, 2021 at 10:12 AM Nick Dunkin <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> I am being asked if Traffic Server can be efficiently run (or run at >>> all) on a disk *poor*, memory *rich *server. The specifics are out of >>> scope for this forum, but the short version is that I’m being asked to make >>> use of some existing hardware. >>> >>> >>> >>> I was considering creating a RAM disk from the several hundred GB of >>> available memory on these servers. >>> >>> >>> >>> Does anyone have any experience of running Traffic Server this way? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Nick >>> >>> >>> >>> *Nick Dunkin* >>> >>> Director, Software Engineering >>> >>> Manager – Architecture and New Product Introduction >>> >>> *o: * *+1 678.258.4071* >>> >>> *e:* [email protected] >>> >>> >>> >>> [image: [email protected]] >>> >>>
