Cannot build variables_hash

Rafa_F · July 25, 2013, 12:49am

Upgraded from 1.2.9 to 1.4.1 and now started getting:

[emerg] could not build the variables_hash, you should increase either
variables_hash_max_size: 512 or variables_hash_bucket_size: 64

Same configuration and even dropped (2) 3rd party modules.

nginx.conf and ./configure params:

gist.github.com

https://gist.github.com/dctrwatson/6075317

nginx-1.2.9 -V

nginx version: nginx/1.2.9
TLS SNI support enabled
configure arguments:
 --prefix=/usr/share/nginx
 --conf-path=/etc/nginx/nginx.conf
 --error-log-path=/var/log/nginx/error.log
 --http-client-body-temp-path=/var/lib/nginx/body
 --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
 --http-log-path=/var/log/nginx/access.log
 --http-proxy-temp-path=/var/lib/nginx/proxy

This file has been truncated. show original

nginx-1.4.1 -V

nginx version: nginx/1.4.1 (Ubuntu)
TLS SNI support enabled
configure arguments:
 --prefix=/usr/share/nginx
 --conf-path=/etc/nginx/nginx.conf
 --error-log-path=/var/log/nginx/error.log
 --http-client-body-temp-path=/var/lib/nginx/body
 --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
 --http-log-path=/var/log/nginx/access.log
 --http-proxy-temp-path=/var/lib/nginx/proxy

This file has been truncated. show original

nginx.conf

user www-data;
worker_processes 1;
worker_rlimit_nofile 63000;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
  worker_connections 1024;
  use epoll;

This file has been truncated. show original

adding this to http block fixes it:
variables_hash_max_size 1024;

Any ideas? Or direction on debugging?

Thanks,

John

princenamor · July 25, 2013, 2:36am

On Wed, Jul 24, 2013 at 03:49:05PM -0700, John W. wrote:

Hi there,

Upgraded from 1.2.9 to 1.4.1 and now started getting:

[emerg] could not build the variables_hash, you should increase either
variables_hash_max_size: 512 or variables_hash_bucket_size: 64

adding this to http block fixes it:
variables_hash_max_size 1024;

Any ideas? Or direction on debugging?

What’s the problem?

You got an error message which asked you to change one of two
directives;
you checked the documentation for those directives which pointed you to
another document which told you which one to change first; you changed
that one; and the error state no longer applies.

It looks perfect from here.

f

Francis D. [email protected]

princenamor · July 25, 2013, 12:55pm

On Jul 25, 2013, at 2:49 AM, John W. [email protected] wrote:

Any ideas? Or direction on debugging?

Hi John,

Any chance you could check it with 1.4.1+ and without any 3rd party
modules?

princenamor · July 29, 2013, 11:45pm

Hi Andrew,

Woops, completely forgot about doing that first before posting here.

It seems the issue is v0.21 of
http://wiki.nginx.org/NginxHttpSRCacheModulethat causes this issue.
I’ll file a bug with agentzh on his Github repo.

Thanks for your help!

princenamor · July 30, 2013, 8:49pm

Hello!

On Mon, Jul 29, 2013 at 2:44 PM, John W. 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.

Regards,
-agentzh

princenamor · August 1, 2013, 1:05am

Hello!

On Wed, Jul 31, 2013 at 7:03 AM, Maxim D. wrote:

How many variables are in total in the configuration in question?

I’ve just checked. There are only 124 variables.

I suspect the real problem is hash collisions.

Yeah, it seems like that

Especially this used
to hit people under qemu where cache line size of an emulated CPU
is detected as 32 by nginx, see here:

Well, this is a modern Linux x86_64 system running on real hardware
though

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.

Yeah, this work-around looks good to me

Best regards,
-agentzh

princenamor · August 2, 2013, 4:02am

Choose your favorite products and items, tell your life to bring some
fun,
welcome to join efox shop

Posted at Nginx Forum:

princenamor · July 31, 2013, 4:04pm

Hello!

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

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 D.
http://nginx.org/en/donation.html

princenamor · August 5, 2013, 4:15am

Want to buy good quality and cheap tablet you, here is a good choice
efox

Posted at Nginx Forum:

princenamor · August 5, 2013, 4:14am

Want to buy good quality and cheap tablet you, here is a good choice
efox

Posted at Nginx Forum: