O tamanho da tabela do formulário de cache é enorme

O tamanho da tabela de cache aumentou para mais de 10 GB no mês passado, e eu a corrigi temporariamente ao truncá-la. A última vez que verifiquei foi de cerca de 1 GB. Assim, em alguns meses, atingirá 10 GB novamente. Como isso deve ser tratado?

Observe que desabilitei todos os trabalhos cron neste site. Se esse for o motivo, qual cron deve ser ativado?

A {cache_form}tabela é um pouco engraçada e se comporta de uma maneira ligeiramente diferente das outras tabelas de cache.

Se você der uma olhada drupal_flush_all_caches(), verá que isso {cache_form}não está limpo. Isso serve para proteger os formulários em andamento de serem bloqueados.

A system_cron()função cuida da remoção de dados antigos {cache_form}das outras tabelas de cache.

Você realmente deve executar o cron em todos os sites do Drupal. Se {cache_form}a tabela é ginourmous, então eu aposto que o seu {watchdog}e {session}mesas são, também. Muitos outros módulos executam atividades de limpeza como parte de suas próprias hook_cron()funções.

Você também pode dar uma olhada na fila de problemas. Ocorreram alguns erros {cache_form}e você pode estar encontrando um.

Regra do polegar: O Cron deve ser executado regularmente para a manutenção do seu site.

Você mencionou em seu comentário ao MPD que, apesar de configurar o cron e executá-lo regularmente, sua tabela cache_form está crescendo rapidamente.

Uma solução para isso é executar o cron com mais frequência. Diga a cada seis horas ou menos? Se você não puder fazer isso, leia mais.

Solução alternativa:

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

Instale o Elysia Cron e agora você pode executar a função cron do seu módulo separadamente. Você pode manter a frequência do Elysia cron para que seu módulo seja executado a cada seis horas. Para que sua cache_formmesa seja podada a cada seis horas.

Durante esse processo de remoção, as entradas que não tenham mais de 6 horas serão excluídas. O motivo é que, se todas as entradas forem excluídas, quaisquer formulários enviados no momento da exclusão das entradas poderão se comportar de maneira estranha.

Veja o código em 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;

Enquanto o comentário diz, eles assumem que deve ser suficiente e, no seu caso, está se tornando demais para você. Portanto, o truque é limpar a tabela cache_form com mais frequência e reduzir o valor de $ expirar para um valor mais baixo, se você desejar limpar as entradas cache_form com mais frequência do que o valor padrão de 6 seis horas, será necessário alterar o TTL de as entradas cache_form.

Você pode fazer isso instalando o cacheboject e implementando o período hook_cacheobject_presaveem que você pode alterar o TTL para 2 ou 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;
  }
}

Uma desvantagem dessa abordagem é que, se os formulários não forem enviados dentro de duas horas (o valor da RTL definido), os dados do formulário poderão ser perdidos e você poderá obter alguns problemas de validade do formulário.

Como solução alternativa para este problema, criei o módulo https://www.drupal.org/project/session_cache_form

Quando eu estava tendo problemas de desempenho em um site em que trabalhava, deparei-me com isso depois de corrigir o cache. Você pode ler o artigo aqui: https://thinktandem.io/blog/2017/11/22/debugging-with-new-relic-blazemeter-strace-more/

No meu blog, você pode adicionar uma fila e uma configuração cron, e usar algo como Elysia Cron para fazer tudo funcionar bem:

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

Use o módulo Limpar cache_form seguro .

Isso permitirá que você corte a tabela em um tamanho razoável primeiro e depois a mantenha.

Resumo extraído da página do projeto:

Remova com segurança um número limitado de itens da tabela cache_form.

Depois que o módulo estiver instalado, remova primeiro cache_form: execute drush safe-cache-form-clearaté que o tamanho da tabela permaneça consistente, indicando que você removeu todos os registros anteriores a 6 horas.

Ele continuará sendo executado no cron.

Este é o módulo documentado para essa finalidade pela Acquia para seus assinantes. A página de documentação do Acquia fornece boas informações adicionais.