Stalled cache updating - what does it mean?

Hello,
I have a pretty basic PHP / fastcgi setup with a fastcgi cache as
follows:

fastcgi_cache_key “$scheme$request_method$host$request_uri”;
fastcgi_cache_lock on;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache MAINCACHE;
fastcgi_cache_valid 5m;

I’m using nginx from the nginx.org Debian repository and building from
source, adding the geoip and ngx_cache_purge modules.

nginx version: nginx/1.5.7
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled

Every so often I’ll get a couple of lines in the log like the following:

2013/12/09 15:59:34 [alert] 14218#0: *10450047 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80
2013/12/09 15:59:34 [alert] 14218#0: *10450055 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80
2013/12/09 15:59:34 [alert] 14218#0: *10450099 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80

This usually occurs after a client requests a script which issues some
internal requests to the site itself (wp-cron).

As it’s log level alert, it seems serious, but I can’t seem to notice
anything wrong as a result. What exactly does this alert mean and is it
something I need to be worried about? I’ve since moved the script to an
offline cron job to see if this helps, but I’m still curious exactly
what
this means.

Thanks,

Rich.

Hello!

On Tue, Dec 10, 2013 at 11:24:33AM +0100, Richard S. wrote:

I’m using nginx from the nginx.org Debian repository and building from
2013/12/09 15:59:34 [alert] 14218#0: *10450055 stalled cache updating,
offline cron job to see if this helps, but I’m still curious exactly what
this means.

The message means that nginx detected an internal problem - the
cache cleanup callback was called on a request termination, and
the r->cache->updating flag, which should be cleared at this
point, is still set. User-visible results are most likely a cache
item which will not be updated, or a cache lock which will apear
to be always set (and requests to a cache item only handled only
after a timeout).

I would suggest to test if you are able to reproduce the problem
without 3rd party modules. If you are, it would be interesting to
see full configuration and a debug log, see
http://wiki.nginx.org/Debugging.


Maxim D.
http://nginx.org/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs