Answers.Body: <p>Anything in <code>queue.log</code> that gives us hints? Anyway if it is just the stale template caches task... I'd just truncate the cache tables manually (n.b.: <strong>truncate</strong>, not <em>delete</em>):</p>
  
  <pre><code>templatecaches
  </code></pre>
  
  <p>You only need to truncate that one cache table, because it'll cascade can remove the other related columns in <code>templatecacheelements</code> and <code>templatecachequeries</code> as well.</p>
  
  <p>Then I'd truncate the <code>queue</code> table as well to remove the no longer needed stale template cache queue jobs.</p>
  
  <p>Learn more:</p>
  
  <ul>
  <li><a href="https://nystudio107.com/blog/zen-and-the-art-of-craft-cms-log-file-reading" rel="nofollow noreferrer">Zen and the Art of Craft CMS Log File Reading</a></li>
  <li><a href="https://nystudio107.com/blog/the-craft-cache-tag-in-depth" rel="nofollow noreferrer">The Craft {% cache %} Tag In-Depth</a></li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-07-24T15:23:29.130Z
Answers.Text: Yikes - my templatecachequeries table was 3GB.Not sure how it got that outta hand but emptying queue table wasn't sufficient. I'd all but removed cache tag too. Once i cleared that all seems to be sweet
Answers.UserDisplayName: joomkit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-07-24T14:50:33.357Z
Answers.LastActivityDate: 2019-07-24T14:50:33.357Z
Answers.UserDisplayName: andrew.welch
Body: <p>So all my background tasks Craft 3.2.6 seem to process ok except deleting stale template caches. Although craft is supposed to fail after 5 minutes, it fails instantly and the error log shows  </p>
  
  <pre><code>Allowed memory size of 1610612736 bytes exhausted (tried to allocate 380928 bytes) 
  </code></pre>
  
  <p>Server settings for memory are 512M and 300 second timeout. The error is instant - in that the error log is immediately populated on saving an entry - which makes me think that this is not the real problem. The server is running Nginx as a reverse proxy for apache and uses microcaching and I wonder if this might interfere with that one task?
  Its a multisite with 8 languages and I guess quite heavy on the fields and image processing. 
  How can I debug this further - short of giving the whole dedicated box memory to this one site? </p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-08T08:14:58.143Z
Comments.Text: I'm fighting with a similar issue (Craft 3.3.18.4)... tried to allocate more memory, increase timeout, but those are not scalable solutions, the deleting jobs are eating up everything you give them.. (Now 2G memory and 600s exec time is already not enough) After flushing the cache the first jobs have already 40K+ steps to complete.. and the number grows exponentially.. some hours later it's 100K+.. I've looked into the queue logs and I see couple of interesting things: 1. There is nothing about deletion. I see only SELECT and UPDATE queries. 2. Everything is logged 3x. (I hope only the logging
Comments.UserDisplayName: peet86
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-17T18:52:16.720Z
Comments.Text: I think its a cache tag problem - this is still ongoing for me but i need to strip out all cache tags and test
Comments.UserDisplayName: joomkit
Tags: <cache><tasks><stalled-tasks>
Title: Deleting stale template stuck fatal memory error
ThreadText: # Deleting stale template stuck fatal memory error
  
  (Asked by: username_0 on 2019-07-24)
  
  So all my background tasks Craft 3.2.6 seem to process ok except deleting stale template caches. Although craft is supposed to fail after 5 minutes, it fails instantly and the error log shows
  
  ```
  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 380928 bytes) 
  
  ```
  
  Server settings for memory are 512M and 300 second timeout. The error is instant - in that the error log is immediately populated on saving an entry - which makes me think that this is not the real problem. The server is running Nginx as a reverse proxy for apache and uses microcaching and I wonder if this might interfere with that one task?
  Its a multisite with 8 languages and I guess quite heavy on the fields and image processing.
  How can I debug this further - short of giving the whole dedicated box memory to this one site?
  
  **Tags:** cache, tasks, stalled-tasks
  
  > **Comments:**
  > **username_1**: I'm fighting with a similar issue (Craft 3.3.18.4)... tried to allocate more memory, increase timeout, but those are not scalable solutions, the deleting jobs are eating up everything you give them.. (Now 2G memory and 600s exec time is already not enough) After flushing the cache the first jobs have already 40K+ steps to complete.. and the number grows exponentially.. some hours later it's 100K+.. I've looked into the queue logs and I see couple of interesting things: 1. There is nothing about deletion. I see only SELECT and UPDATE queries. 2. Everything is logged 3x. (I hope only the logging  
  > **username_0**: I think its a cache tag problem - this is still ongoing for me but i need to strip out all cache tags and test  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-07-24. Score: 1 | Accepted answer
  
  Anything in `queue.log` that gives us hints? Anyway if it is just the stale template caches task... I'd just truncate the cache tables manually (n.b.: **truncate**, not *delete*):
  
  ```
  templatecaches
  
  ```
  
  You only need to truncate that one cache table, because it'll cascade can remove the other related columns in `templatecacheelements` and `templatecachequeries` as well.
  
  Then I'd truncate the `queue` table as well to remove the no longer needed stale template cache queue jobs.
  
  Learn more:
  
  * [Zen and the Art of Craft CMS Log File Reading](https://nystudio107.com/blog/zen-and-the-art-of-craft-cms-log-file-reading)
  * [The Craft {% cache %} Tag In-Depth](https://nystudio107.com/blog/the-craft-cache-tag-in-depth)
  
  > **Comments:**
  > **username_0**: Yikes - my templatecachequeries table was 3GB.Not sure how it got that outta hand but emptying queue table wasn't sufficient. I'd all but removed cache tag too. Once i cleared that all seems to be sweet  
  
  ---
  
  