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