trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Morilha <>
Subject Re: Can ATS keep more than 500mbit/s traffic for single instance?
Date Mon, 25 Nov 2013 18:49:33 GMT
I will jump in and ask if TSMalloc does more than what it is reported on
the documentation (
I've also seen there are configuration options to use jemalloc and tcmalloc
(I assume, they are hooked up into TSMalloc).

The reason I am interested on that is that so far I've been avoiding
TSMalloc in favor of standard C++ new/delete allocators. So if TSMalloc
actually might have some (good) impact in performance it might be
interesting into providing a TS specific C++ allocator using them.

What you guys suggest?


On Fri, Nov 22, 2013 at 8:02 PM, Leif Hedstrom <> wrote:

> On Nov 21, 2013, at 9:11 PM, James Peach <> wrote:
> >
> > On Nov 21, 2013, at 7:57 PM, Adam W. Dace <>
> 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.
> >
> > 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
> 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

Daniel Morilha (

View raw message