Closed stgleb closed 7 years ago
Also there is such kind of message in logs
2017/08/11 12:04:48 [alert] 28758#28758: shared memory zone "51Degrees Shared Cache" was locked by 28766
http://codegists.com/code/preproc%20java/
51D_cache 0; # crucial - otherwise crashes might occur
Hi @stgleb
Could you provide the following information in order to help us diagnose the issue:
Regards, Joe
Hi We use those software
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads
OS on which we run nginx
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
we are building 51D from source and have gcc
ii gcc 4:4.8.2-1ubuntu6 amd64 GNU C compiler
ii gcc-4.8 4.8.4-2ubuntu1~14.04.3 amd64 GNU C compiler
ii gcc-4.8-base:amd64 4.8.4-2ubuntu1~14.04.3 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-4.8-base:i386 4.8.4-2ubuntu1~14.04.3 i386 GCC, the GNU Compiler Collection (base package)
ii gcc-4.9-base:amd64 4.9.3-0ubuntu4 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-4.9-base:i386 4.9.3-0ubuntu4 i386 GCC, the GNU Compiler Collection (base package)
ii lib32gcc1 1:4.9.3-0ubuntu4 amd64 GCC support library (32 bit Version)
ii libgcc-4.8-dev:amd64 4.8.4-2ubuntu1~14.04.3 amd64 GCC support library (development files)
ii libgcc1:amd64 1:4.9.3-0ubuntu4 amd64 GCC support library
ii libgcc1:i386 1:4.9.3-0ubuntu4 i386 GCC support library ```
and OS
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
we are building 51D from source
- i mean that we build module of 51D fo nginx
We have tied to use
51D_cache 0;
And that is resolve problem. I'm not sure that will work when we get more then 2-3K active connection but now its work
Also what do this parameter?
Thanks for the information, I will try to recreate the issue.
51D_Cache sets the size of the target User-Agents cache and the results set cache. This is used in pattern mode to reduce calls to the data set.
Regards, Joe
@stgleb @DeamonMV Thanks for bringing this up, this is a bug which did not get caught in any of our tests as it only happens in a very specific scenario.
The error is occurring when two worker processes match the same set of HTTP headers and try to insert the identical matches into the cache at the same time. Process 1 will lock the cache, insert the match, unlock the cache, then return. Then process 2 will lock the cache, dispose of its match (as it has already been added to the cache by process 1), then return without unlocking the cache. You can see this on line 768 of the module source.
As you can tell, this has not come up for so long as it requires a set of HTTP headers which present in the cache already to arrive at two worker processes in the same <1ms window in order for this to happen.
I have attached a patch which fixes this bug, and it will be included in our next release.
0001-BUG-User-Agent-cache-in-the-shared-memory-zone-lock.patch.zip
Regards, Ben
I am using 51 degrees built as nginx loadable module. But each time I turn on it I've got and error
nginx.conf
This is location