Hello!

On Tue, Jul 30, 2013 at 11:49:35AM -0700, Yichun Zhang (agentzh) wrote:

> Hello!
>
> On Mon, Jul 29, 2013 at 2:44 PM, John Watson wrote:
> > It seems the issue is v0.21 of http://wiki.nginx.org/NginxHttpSRCacheModule
> > that causes this issue. I'll file a bug with agentzh on his Github repo.
> >
>
> Just for the reference, there is no bugs in ngx_srcache.
>
> It's just that enabling many nginx modules (including standard ones
> and 3rd-party ones) exceeds the variables_hash_max_size limit (default
> value). See below for more details:
>
> https://github.com/agentzh/srcache-nginx-module/issues/21
>
> Given the current rich ecosystem of nginx, maybe the nginx core should
> increase the default value of variables_hash_max_size? Not sure
> though.

How many variables are in total in the configuration in question?
Standard nginx with almost all modules compiled in (and a few
extra modules) here has just 114 variables, and 512 looks big
enough.

I suspect the real problem is hash collisions. Especially this used
to hit people under qemu where cache line size of an emulated CPU
is detected as 32 by nginx, see here:

http://trac.nginx.org/nginx/ticket/352

Not sure how to properly address it though. Right now I think
just automatically doubling bucket_size if we wasn't able to build
hash might be a good idea.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx