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


1 Answer 1


See these for help debugging stuck tasks:

Generating pending image transforms stuck in process

Deleting Stale Template Caches Failed


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

See here for an explanation on how all of that works.

The cacheMethod config setting, which is what you've set to memcache affects any PHP code in Craft that is using craft()->cache (including plugins).

See these for more discussion on it:

How much data can craft()->cache hold?

Use cache instead of saving to database

  • 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.
    Commented Feb 27, 2015 at 18:11
  • No issues since the changes. Also, forgot to mention that the cache information was very helpful. Thanks.
    – Mathieu P.
    Commented Mar 2, 2015 at 15:55
  • @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
    Commented Mar 26, 2015 at 21:40
  • @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.
    Commented Mar 28, 2015 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.