stalled cache updating - what does it mean?

Maxim Dounin mdounin at mdounin.ru
Tue Dec 10 10:58:08 UTC 2013


Hello!

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

> 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.

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 Dounin
http://nginx.org/



More information about the nginx mailing list