Closed (cannot reproduce)
Project:
Drupal core
Version:
6.19
Component:
cache system
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
30 Oct 2010 at 09:41 UTC
Updated:
29 May 2015 at 21:15 UTC
Jump to comment: Most recent
Comments
Comment #1
eric_a commentedEvery single form build takes 6 hours to expire. If your site has many forms and many, many hits, you will have many form builds and this cache bin will grow. Do you have any evidence that cache_form entries are never cleared at cron time, while entries from other tables do?
Comment #3
grendzy commentedComment #4
tr commentedI cannot reproduce this in Drupal 6 or Drupal 7. Each row in the cache_form table has an expiration time. When cron runs, any row past its expiration time will be deleted. Like Eric_A said, it takes about 6 hours for a row to expire. If there are no expired rows, cron will not appear to do anything. The cache_form table is never cleared completely by cron - only the expired rows are cleared.
Comment #5
tr commentedDouble post.
Comment #6
giorgoskbig database tables might need optimizing to get rid of overhead
I would give http://drupal.org/project/db_maintenance a try
Comment #7
giorgio79 commented#1506196: cache_form is never cleared on some sites similar request
Comment #8
saitanay commentedDELETED
Comment #9
Anonymous (not verified) commentedFor what it's worth, I recently ran into this with Drupal 7 and a 42GB cache_form table. What was happening in my case was at some point (I think around 24-25GB) the cache_form table became too large to clear on that particular system. The reason it became too large to clear is because MySQL would run out of disk space because of a combination of the binlog generated and the temporary storage used during that DELETE query in case of a rollback. After MySQL crashed and restarted, the temporary storage had been cleared so it was hard to see that it was an out of disk space issue.
Drupal also doesn't tell you if there was a failure in that manner.