<p>See these for help debugging stuck tasks:</p>

<p><a href="https://craftcms.stackexchange.com/questions/2375/generating-pending-image-transforms-stuck-in-process/2389#2389">Generating pending image transforms stuck in process</a></p>

<p><a href="https://craftcms.stackexchange.com/questions/4329/deleting-stale-template-caches-failed/4338#4338">Deleting Stale Template Caches Failed</a></p>

<p><a href="http://buildwithcraft.com/help/stuck-tasks" rel="nofollow">http://buildwithcraft.com/help/stuck-tasks</a></p>

<p>As far as what cache gets saved where, template caches (the <code>{% cache %}</code> tag) always get saved in the database.</p>

<p>See <a href="https://craftcms.stackexchange.com/questions/6633/how-does-template-caching-work">here</a> for an explanation on how all of that works.</p>

<p>The <a href="http://buildwithcraft.com/docs/config-settings#cacheMethod" rel="nofollow">cacheMethod</a> config setting, which is what you've set to <code>memcache</code> affects any PHP code in Craft that is using <a href="http://buildwithcraft.com/classreference/services/CacheService" rel="nofollow">craft()->cache</a> (including plugins).</p>

<p>See these for more discussion on it:</p>

<p><a href="https://craftcms.stackexchange.com/questions/4131/how-much-data-can-craft-cache-hold">How much data can craft()-&gt;cache hold?</a></p>

<p><a href="https://craftcms.stackexchange.com/questions/4381/use-cache-instead-of-saving-to-database">Use cache instead of saving to database</a></p>

CC BY-SA 3.0
2015-02-27T18:11:21.893Z
While fixing a previous "504 Gateway Timed Out" issue, I configured a max execution timeout of 300 to PHP, PHP-FPM, and NGINX FastCGI.

After more investigation, I ended up removing the "request_terminate_timeout" in PHP-FPM and leaving that one at the default (off).  So for the gateway timeout, only PHP "max_execution_time = 300" and the "fastcgi_read_timeout 300" are in place.  I eventually got a "failed" job instead of a "stuck" job and got some logs!  To fix that issue I increased MySQL "max_user_connections" (which was at 50).

I will report back if I get another stuck job.  Thanks!
Mathieu P.
CC BY-SA 3.0
2015-03-02T15:55:57.393Z
No issues since the changes.  Also, forgot to mention that the cache information was very helpful. Thanks.
Mathieu P.
CC BY-SA 3.0
2015-03-26T21:40:04.837Z
@MathieuP. We are having the same issue. What type of server are you on.? What version of PHP and mysql are you using? I am trying to determine we need to make similar tweaks.
a-am
CC BY-SA 3.0
2015-03-28T01:55:09.337Z
@aran I'm quite certain that my changes are not tied to a specific version of any component in the stack.  The Nginx and PHP-FPM timeouts, and the MySQL max_user_connections settings are available in all versions...  Maybe the defaults are different, you will have to compare with the values I listed above.
Mathieu P.
CC BY-SA 3.0
2015-02-18T22:58:06.180Z
2015-02-18T22:58:06.180Z
Brad Bell
<p>We have only two templates leveraging the cache tag and they both have a construct similar to:</p>

<pre><code>{% extends "_layout" %}

{% block content %}
  {% cache globally using key entry.url ~ "relatedArticles" for 1 hour %}
    ... bunch of relational queries ...
  {% endcache %}
  ...
{% endblock %}
</code></pre>

<p>Once or twice a day, the <code>DeleteStaleTemplateCaches</code> get stuck and requires manual "killing".  For example, when this occurs, the <code>craft_tasks</code> table indicates say <code>currentStep</code> 1309 of <code>totalSteps</code> 12800...  Then, "<em>error'ing</em>" the task, and choosing the "<em>Retry task</em>", generate a new job but will say only 670 <code>totalSteps</code>...  and of course it succeeds.  Why is the total steps so much different on retry? </p>

<p>There is no clue in the logs.  Only the logs of the "retried task" that show the steps and its successful result.  Nothing about the stuck task that I killed.</p>

<p>Currently, we have 3 nodes sharing a common file system for all (except most of the "runtime folder") and common database but individual memcached server (one per node).  Craft is configured to use memcached.  Could the issue be that more than one node start the delete task at the same time?  i.e. all try to cleanup the same db table?  </p>

<p>Beside this specific problem, I would be very grateful if you could explain how the different caching (data, templates, etc.)  works within craft or indicate where I can find the information. i.e. I'm not clear on what is cached in memcached vs the database, vs file system (if anything).</p>

<p>Thanks.</p>

<cache><caching>
DeleteStaleTemplateCaches job getting stuck
# DeleteStaleTemplateCaches job getting stuck

(Asked by: username_0 on 2015-02-18)

We have only two templates leveraging the cache tag and they both have a construct similar to:
{% extends "_layout" %}

{% block content %}
  {% cache globally using key entry.url ~ "relatedArticles" for 1 hour %}
    ... bunch of relational queries ...
  {% endcache %}
  ...
{% endblock %}

Once or twice a day, the DeleteStaleTemplateCaches get stuck and requires manual "killing".  For example, when this occurs, the craft_tasks table indicates say currentStep 1309 of totalSteps 12800...  Then, "error'ing" the task, and choosing the "Retry task", generate a new job but will say only 670 totalSteps...  and of course it succeeds.  Why is the total steps so much different on retry? 
There is no clue in the logs.  Only the logs of the "retried task" that show the steps and its successful result.  Nothing about the stuck task that I killed.
Currently, we have 3 nodes sharing a common file system for all (except most of the "runtime folder") and common database but individual memcached server (one per node).  Craft is configured to use memcached.  Could the issue be that more than one node start the delete task at the same time?  i.e. all try to cleanup the same db table?  
Beside this specific problem, I would be very grateful if you could explain how the different caching (data, templates, etc.)  works within craft or indicate where I can find the information. i.e. I'm not clear on what is cached in memcached vs the database, vs file system (if anything).
Thanks.

**Tags:** cache, caching


---

## 1 answers

### Answer by username_1 on 2015-02-18. Score: 3 | Accepted answer

See these for help debugging stuck tasks:

[Generating pending image transforms stuck in process](https://craftcms.stackexchange.com/questions/2375/generating-pending-image-transforms-stuck-in-process/2389#2389)

[Deleting Stale Template Caches Failed](https://craftcms.stackexchange.com/questions/4329/deleting-stale-template-caches-failed/4338#4338)

<http://buildwithcraft.com/help/stuck-tasks>

As far as what cache gets saved where, template caches (the `{% cache %}` tag) always get saved in the database.

See [here](https://craftcms.stackexchange.com/questions/6633/how-does-template-caching-work) for an explanation on how all of that works.

The [cacheMethod](http://buildwithcraft.com/docs/config-settings#cacheMethod) config setting, which is what you've set to `memcache` affects any PHP code in Craft that is using [craft()->cache](http://buildwithcraft.com/classreference/services/CacheService) (including plugins).

See these for more discussion on it:

[How much data can craft()->cache hold?](https://craftcms.stackexchange.com/questions/4131/how-much-data-can-craft-cache-hold)

[Use cache instead of saving to database](https://craftcms.stackexchange.com/questions/4381/use-cache-instead-of-saving-to-database)

> **Comments:**
> **username_0**: While fixing a previous "504 Gateway Timed Out" issue, I configured a max execution timeout of 300 to PHP, PHP-FPM, and NGINX FastCGI.  After more investigation, I ended up removing the "request_terminate_timeout" in PHP-FPM and leaving that one at the default (off).  So for the gateway timeout, only PHP "max_execution_time = 300" and the "fastcgi_read_timeout 300" are in place.  I eventually got a "failed" job instead of a "stuck" job and got some logs!  To fix that issue I increased MySQL "max_user_connections" (which was at 50).  I will report back if I get another stuck job.  Thanks!  
> **username_0**: No issues since the changes.  Also, forgot to mention that the cache information was very helpful. Thanks.  
> **username_2**: @MathieuP. We are having the same issue. What type of server are you on.? What version of PHP and mysql are you using? I am trying to determine we need to make similar tweaks.  
> **username_0**: @aran I'm quite certain that my changes are not tied to a specific version of any component in the stack.  The Nginx and PHP-FPM timeouts, and the MySQL max_user_connections settings are available in all versions...  Maybe the defaults are different, you will have to compare with the values I listed above.  

---

