El tamaño de la tabla del formulario de caché es enorme

El tamaño de la tabla de caché aumentó a más de 10 GB el mes pasado, y lo arreglé temporalmente truncándolo. La última vez que lo revisé fue de alrededor de 1 GB. Entonces, en un par de meses, alcanzará nuevamente los 10 GB. ¿Cómo debería tratarse esto?

Tenga en cuenta que he desactivado todos los trabajos cron en este sitio. Si esta es la razón, ¿qué cron debería habilitarse?

La {cache_form}tabla es un poco divertida y se comporta de manera ligeramente diferente a otras tablas de caché.

Si echas un vistazo drupal_flush_all_caches(), verás que {cache_form}no está despejado. Esto es para proteger los formularios en progreso de ser destruidos.

La system_cron()función se encarga de eliminar los datos antiguos {cache_form}junto con las otras tablas de caché.

Realmente deberías ejecutar cron en todos los sitios de Drupal. Si {cache_form}la tabla es ginourmous, a continuación, apuesto a que tu {watchdog}y {session}tablas son, también. Muchos otros módulos ejecutan actividades de limpieza como parte de sus propias hook_cron()funciones.

También es posible que desee hurgar en la cola de problemas. Se han producido algunos errores {cache_form}y es posible que te encuentres con uno.

Regla del pulgar: Cron debe ejecutarse regularmente para el mantenimiento de su sitio web.

Usted mencionó en su comentario a MPD que, a pesar de configurar el cron y ejecutarlos regularmente, su tabla cache_form está creciendo rápidamente.

Una solución para eso es ejecutar su cron con más frecuencia. ¿Digamos cada seis horas o menos? Si no puede permitirse el lujo de hacerlo, lea más.

Solución alternativa

mymodule_cron() {
    cache_clear_all(NULL, 'cache_form');
}

Instale Elysia Cron y ahora puede ejecutar la función cron de su módulo por separado. Puede mantener la frecuencia del cron de Elysia para que su módulo se ejecute cada seis horas. Para que su cache_formmesa se pode cada seis horas.

Durante este proceso de poda, las entradas que no tengan más de 6 horas no se eliminarán. La razón es que si se eliminan todas las entradas, cualquier formulario que se envíe al momento de eliminar las entradas puede comportarse de manera extraña.

Mire el código en https://api.drupal.org/api/drupal/includes!form.inc/function/form_set_cache/7

function form_set_cache($form_build_id, $form, $form_state) {
  // 6 hours cache life time for forms should be plenty.
  $expire = 21600;

A medida que se lee el comentario, están asumiendo que debería ser suficiente y, en su caso, se está volviendo demasiado para usted. Entonces, el truco es borrar la tabla cache_form con más frecuencia y reducir el valor de $ expire a un valor inferior, si desea borrar las entradas cache_form con más frecuencia que el valor predeterminado de 6 seis horas, entonces necesita alterar el TTL de Las entradas cache_form.

Puede hacerlo instalando cacheboject y luego implementando hook_cacheobject_presavedentro de lo cual puede alterar el TTL que puede ser de 2 o 3 horas.

mymodule_cacheobject_presave()($object, $cid, $bin) {
  // Extend the expiry period for prototype forms used in ajax enabled forms.                                                                  
  $cache_ttl = 1 ; // Change it to any number of hours
  if ($bin == 'cache_form') {
    $object->expire = REQUEST_TIME + $cache_ttl * 3600;
  }
}

Una desventaja de este enfoque es que si los formularios no se envían dentro de las 2 horas (el valor RTL que estableció), los datos del formulario se pueden perder y es posible que algunos problemas expiren.

Como solución a este problema, he creado el módulo https://www.drupal.org/project/session_cache_form

Cuando tenía problemas de rendimiento en un sitio en el que trabajaba, me encontré con esto después de arreglar el almacenamiento en caché. Puede leer el artículo aquí: https://thinktandem.io/blog/2017/11/22/debugging-with-new-relic-blazemeter-strace-more/

Desde mi publicación de blog, puede agregar una configuración de cola y cron, luego usar algo como Elysia Cron para que todo funcione bien:

/**
 * Implements hook_cron_queue_info()
 */
function THE MODULE_cron_queue_info() {
  // Set up the worker queue.
  $queues['THE MODULE_queue'] = array(
    'worker callback' => 'THE MODULE_queue_process',
    'time' => 600,
  );
  return $queues;
}

/**
 * Implements hook_cron()
 */
function THE MODULE_cron() {
  // Load up our worker queue.
  $queue = DrupalQueue::get('THE MODULE_queue');

  // Set up the query for expired results.
  $sql = "SELECT cid FROM {cache_form} WHERE expire < :time";
  $query = db_query($sql, array(':time' => REQUEST_TIME));
  $results = $query->fetchAll(PDO::FETCH_ASSOC);

  // Split this into chunks for safety and speed.
  $chunks = array_chunk($results, 5000);
  foreach ($chunks as $chunk) {
    // Add the chunk to the queue worker.
    $queue->createItem($chunk);
  }
}

/**
 * Worker callback defined in hook_cron_queue_info().
 *
 * @param array $data
 *   The array of cids we want to delete.
 */
function THE MODULE_queue_process($data) {
  db_delete('cache_form')
    ->condition('cid', $data, 'IN')
    ->execute();
}

Utilice el módulo Safe cache_form Clear .

Primero le permitirá podar la mesa a un tamaño razonable y luego mantenerla.

Resumen extraído de la página del proyecto:

Elimine de forma segura un número limitado de elementos de la tabla cache_form.

Una vez que el módulo está instalado, primero pode cache_form: ejecutar drush safe-cache-form-clearhasta que el tamaño de la tabla se mantenga constante, lo que indica que ha eliminado todos los registros anteriores a 6 horas.

Luego continuará ejecutándose en cron.

Este es el módulo documentado para este propósito por Acquia para sus suscriptores. La página de documentación de Acquia proporciona buena información adicional.