O comando `drush cc all` leva muito tempo, o que posso fazer?

Em um site meu drush cc allleva mais de 4 minutos para ser executado. O site db tem alguns GBs. No entanto, não vejo uma razão clara do motivo de demorar demais. O que posso fazer para localizar o gargalo da garrafa?

O cache de limpeza não demora muito, pois está apenas truncando as tabelas de cache. O que leva mais tempo é a reconstrução do registro de cache depois disso. Geralmente, é o registro do tema que verifica todos os novos ganchos e todas as pastas do Drupal em busca de novos arquivos de modelo, o sistema que verifica os novos módulos e arquivos de classe e similares.

Você sempre pode limpar o cache específico especificando drush cc theme-registryou qualquer outro.

É altamente recomendável que você use o mecanismo de cache do PHP (por exemplo, OPCache, XCache, etc.) para acelerar o processamento. E cache baseado em memória para substituir o uso pesado em tabelas SQL (por exemplo, memcached ou redis), para limpar o cache não levaria tempo, apenas liberando o cache (por exemplo, echo flush_all > /dev/tcp/127.0.0.1/11211no Bash).

Como alternativa, você sempre pode limpar o cache manualmente , por exemplo:

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

Depuração

Para verificar o que está demorando mais, especificamente, você precisa depurar / criar um perfil (por exemplo, XDebug, XHProf, phpdbg, dtrace).

No OS X / Unix, isso pode ser alcançado dtrace(após a execução drush):

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

No Linux, use strace, por exemplo,

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

A olhar para algumas coisas específicas, tente adicionar por exemplo: strace ... 2>&1 | grep -C5 UPDATE.

Se você possui um banco de dados muito grande e seu sistema está funcionando bem quando você não está limpando o cache, é provável que você não tenha memória suficiente para dar suporte total à sua configuração.

Se seu site estiver sendo executado em uma caixa Linux, execute 'top' (no seu shell) e pressione Shift-M para classificar a lista de processos pela memória usada. Em seguida, execute sua operação de limpeza de cache em outro terminal. Você deve ver o mysql e o apache subirem para o topo da lista. Você poderá ver qual porcentagem da memória total cada um desses processos está usando e quanta RAM livre é usada. Se você tiver uma grande quantidade de espaço virtual, mas toda a sua RAM física estiver esgotada, essa operação poderá estar causando o problema da memória da VM, o que pode levar o tempo de execução a uma pequena fração do que normalmente é.

Uma vez, eu estava executando um site Drupal no meio do tráfego em uma caixa sem memória suficiente para suportar a instalação. Quando executei uma limpeza de cache em um site de baixo tráfego não relacionado, a reconstrução do cache empurrou o sistema além do limite e tudo estava bloqueado. Portanto, o comportamento total do sistema é importante aqui; é por isso que ferramentas simples como 'top' são um local útil para começar.

Vou discordar (um pouco) com @ greg_1_anderson aqui.

Se o sistema não estiver travando totalmente durante um cc all, não acho que você tenha um problema geral de memória. Quando um servidor LAMP fica sem memória, ele bate em swap. Um servidor ativo que bate na troca causará uma avalanche de maldade. processos httpd começarão a se acumular devido à lentidão do sistema (a troca faz com que o sistema funcione muito lentamente), o que fará com que mais troca seja usada etc. Nos sites em que eu vi isso acontecer, veria a carga do processo atingir 100, e uma tonelada de processos httpd ativos.

Se o seu sistema finalmente voltar, acho que você está mal ajustado. drush cc allresultará em muitos acessos ao banco de dados, então acho que está mostrando mais o problema. Minha sugestão seria executar o mysqltuner no site. Se você possui um banco de dados com vários GB, meu palpite é que seu innodb_buffer_pool_sizetamanho não é remotamente adequado e sua instância do MySQL está se debatendo. Eu também investigaria um back-end de cache alternativo para tentar manter a área de cobertura do banco de dados menor.

Pode ser o seu ambiente de hospedagem na web. Você está se referindo a uma configuração local ou a algo hospedado em hospedagem compartilhada ou em um VPS / servidor?

• ambiente de hospedagem - se você estiver hospedado na web compartilhada, a quantidade de memória que o Drupal / drush pode usar será limitada, consulte: https://drupal.org/node/207036
• tempo máximo de execução - precisa ser aumentado

Esta não é uma solução completa, apenas mais uma ferramenta para ajudar a identificar a origem dos seus atrasos.

Além de usar toppara monitorar processos, você pode encontrar a saída de mytopinformativo. (Outras respostas acima pressupõem o MySQL, mas se você estiver usando outro back-end do banco de dados, precisará trocar o mytop por uma ferramenta equivalente.)

mytopsimplesmente executa o MySQL SHOW FULL PROCESSLISTem um loop e mostra quais consultas estão sendo executadas (o que leva muito tempo). Se a limpeza do cache estiver demorando muito para limpar esta ou aquela tabela, você verá exatamente o que está segurando as coisas aqui. Se você não tem acesso para instalar mytop, basta fazer uma versão bruta no seu shell -

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

Se o atraso não deriva das consultas do MySQL, essa ferramenta pode pelo menos confirmar isso para você.

Encontrei uma postagem no blog intitulada Acelerar a limpeza de cache no Drupal 7 para ser muito útil para restringir com precisão qual parte do processo de limpeza de cache estava atrasando as coisas. Os problemas apontados no módulo de recursos e no módulo de API da entidade estavam afetando meu site, mas o processo detalhado na postagem também me ajudou a rastrear problemas que estávamos enfrentando no núcleo e no módulo de pontos de interrupção do Drupal .

Demora algum tempo para trabalhar no processo, mas me ajudou a reduzir a limpeza de cache de vários minutos para menos de um minuto.