On Nov 21, 2013, at 9:11 PM, James Peach <[email protected]> wrote:
>
> On Nov 21, 2013, at 7:57 PM, Adam W. Dace <[email protected]> wrote:
>
>> Also, once you've gotten past your immediate problem and are looking to
>> deploy my Wiki page may help:
>>
>> https://cwiki.apache.org/confluence/display/TS/WebProxyCacheTuning
>>
>> 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.
>
> Yes, that's a nice piece of work! The effect ofproxy.config.system.mmap_max
> is interesting; were you ble to test with tcmalloc?
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
https://issues.apache.org/jira/browse/TS-1822
Curious, when you increased this, did you also increase the corresponding
sysctl? That would be
kernel.shmall
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).
— Leif
