> Yes, that's a nice piece of work! The effect ofproxy.config.system.mmap_max is interesting; were you ble to test with tcmalloc?
On Nov 21, 2013, at 9:11 PM, James Peach <email@example.com> wrote:
> On Nov 21, 2013, at 7:57 PM, Adam W. Dace <firstname.lastname@example.org> wrote:
>> Also, once you've gotten past your immediate problem and are looking to deploy my Wiki page may help:
>> To call it "best practices" would be a bit much, but I spent quite a bit of time simply tuning ATS for my own uses.
>> The page is finally stable(i.e. I'm done now) and I'm quite pleased. I'm hoping once the next release is out the door
>> I can start bugging the commiters to take a look and review it.
Yeah, I’m very curious and concerned about this at the same time. The background is that we used to do millions of mmap areas for the RAM cache. As far as I can tell, this is no longer true (but please correct me if I’m wrong). As such, we were even thinking of removing this configuration option entirely, see
Curious, when you increased this, did you also increase the corresponding sysctl? That would be
Meaning, unless you increased this setting above the default, increasing the ATS setting above that ought to have no impact. Also, on a box we run with 100GB of RAM cache, the total number of pages mmap’ed is only about 500, a far cry from where we’d need to increase proxy.config.system.mmap_max. The default for this setting is 2MB, but the system default is 64KB.
Finally, why this setting would affect disk I/O is a conundrum. As far as I know, our main mmap usage is for the RAM cache.
James, you got any brilliant thoughts / ideas on why this is ? We should perhaps test one of our prod boxes with mmap_max set to something much smaller (e.g. 64k).