Le dimensioni della tabella del modulo cache sono enormi

Le dimensioni della tabella della cache sono aumentate a 10+ GB il mese scorso e l'ho risolto temporaneamente troncandolo. L'ultima volta che ho controllato era di circa 1 GB. Quindi tra un paio di mesi colpirà di nuovo 10 GB. Come dovrebbe essere affrontato?

Nota che ho disabilitato tutti i lavori cron su questo sito. Se questo è il motivo, quale cron dovrebbe essere abilitato?

La {cache_form}tabella è un po 'divertente e si comporta in modo leggermente diverso rispetto alle altre tabelle cache.

Se dai un'occhiata drupal_flush_all_caches()vedrai che {cache_form}non è stato cancellato. Questo per proteggere le forme in corso dall'essere bombardate.

La system_cron()funzione si occupa di eliminare i vecchi dati {cache_form}insieme alle altre tabelle della cache.

Dovresti davvero eseguire cron su tutti i siti Drupal. Se si {cache_form}tabella è ginourmous, allora scommetto la vostra {watchdog}e {session}tavoli sono, anche. Molti altri moduli svolgono attività di pulizia come parte delle proprie hook_cron()funzioni.

Potresti anche voler curiosare nella coda dei problemi. Ci sono stati alcuni bug {cache_form}e potresti trovarne uno.

Thumb Rule: Cron dovrebbe essere eseguito regolarmente per le pulizie del tuo sito web.

Nel tuo commento a MPD hai menzionato che, nonostante la configurazione di cron e l'esecuzione periodica, la tabella cache_form sta crescendo rapidamente.

Una soluzione è quella di eseguire il cron più frequentemente. Dire ogni sei ore o meno? Se non puoi permetterti di farlo, leggi oltre.

Soluzione alternativa:

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

Installa Elysia Cron e ora puoi eseguire la funzione cron del tuo modulo separatamente. Puoi mantenere la frequenza del cron Elysia affinché il tuo modulo funzioni ogni sei ore. In modo che la tua cache_formtavola venga potata ogni sei ore.

Durante questo processo di potatura le voci non più vecchie di 6 ore non verranno eliminate. Il motivo è che, se tutte le voci vengono eliminate, tutti i moduli che vengono inviati al momento dell'eliminazione delle voci possono comportarsi in modo strano.

Guarda il codice in 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;

Mentre il commento legge stanno assumendo che dovrebbe essere abbondante e nel tuo caso sta diventando troppo per te. Quindi il trucco è cancellare la tabella cache_form più frequentemente e ridurre il valore di $ expire a un valore inferiore, se si desidera cancellare le voci cache_form più frequentemente del valore predefinito di 6 sei ore, è necessario modificare il TTL di le voci cache_form.

Puoi farlo installando cacheboject e quindi implementando hook_cacheobject_presaveentro il quale è possibile modificare il TTL in 2 o 3 ore.

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;
  }
}

Un aspetto negativo di questo approccio è se i moduli non vengono inviati entro 2 ore (il valore RTL impostato) i dati del modulo potrebbero andare persi e si potrebbero verificare problemi con i moduli scaduti.

Per ovviare a questo problema, ho creato il modulo https://www.drupal.org/project/session_cache_form

Quando stavo riscontrando problemi di prestazioni su un sito in cui stavo lavorando, mi sono imbattuto in questo dopo aver corretto la memorizzazione nella cache. Puoi leggere l'articolo qui: https://thinktandem.io/blog/2017/11/22/debugging-with-new-relic-blazemeter-strace-more/

Dal mio post sul blog, puoi aggiungere una configurazione di coda e cron, quindi utilizzare qualcosa come Elysia Cron per far funzionare tutto bene insieme:

/**
 * 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();
}

Utilizzare il modulo Clear cache_form Clear .

Ti permetterà di potare prima la tabella a una dimensione ragionevole, quindi di mantenerla.

Estratto riassunto dalla pagina del progetto:

Rimuovere in sicurezza un numero limitato di elementi dalla tabella cache_form.

Una volta installato il modulo, elimina prima cache_form: esegui drush safe-cache-form-clearfino a quando le dimensioni della tabella rimangono coerenti, a indicare che hai rimosso tutti i record più vecchi di 6 ore.

Continuerà quindi a funzionare su cron.

Questo è il modulo documentato a tale scopo da Acquia per i propri abbonati. La pagina della documentazione di Acquia fornisce buone informazioni aggiuntive.