Il comando `drush cc all` richiede troppo tempo, cosa posso fare?

12

In un mio sito ci drush cc allvogliono più di 4 minuti per correre. Il sito db è di pochi GB. Tuttavia, non riesco a vedere un motivo chiaro per cui ci vuole troppo tempo. Cosa posso fare per localizzare il collo della bottiglia?

7 drush caching

— AWM
fonte

Controlla il primo log delle query mysql: drupal.stackexchange.com/questions/75629/…

— AgA

Hai cron in esecuzione?

— mpdonadio

Sì, ho un cron in esecuzione. Il sito è lento in generale. Tanti codici legacy che non vale la pena ricoprire.

— awm

Sono d'accordo con @MPD qui, non penso che questo sia legato alla memoria. MySQL è anche solo uno dei possibili motivi. C'è solo un modo per scoprirlo e questo è profilarlo. Il modo più semplice per farlo è usare l'estensione e lo sviluppo xhprof, che funziona anche con drush (usa -d per vedere il link al rapporto). La mia ipotesi è che ci siano una serie di problemi, un problema tipico se il sito è lento per tutte le richieste mancano i moduli, vedere drupal.stackexchange.com/questions/724/why-is-drupal-7-so-slow . Views presenta anche alcuni importanti problemi di prestazioni con le cache, vedi drupal.org/node/1944674 .

— Berdir,

Grazie, ho pensato che avrei dovuto fare la profilazione, ma nel caso della base di codice drupal, è sempre difficile individuare il collo di bottiglia. Anche se ho detto che il sito è lento, non è troppo lento e drush cc tutto, è sproporzionatamente più lento.

— awm

6

La cancellazione automatica della cache non richiede molto tempo, poiché sta semplicemente troncando le tabelle della cache. Ciò che richiede di più è ricostruire il registro della cache dopo quello. Di solito è il registro dei temi che esegue la scansione di tutti i nuovi hook e di tutte le cartelle Drupal alla ricerca di nuovi file modello, sistema che esegue la scansione dei file per i nuovi moduli e file di classe e simili.

Puoi sempre svuotare la cache specifica specificando drush cc theme-registryo qualsiasi altra.

Si consiglia vivamente di utilizzare il meccanismo di memorizzazione nella cache di PHP (ad esempio OPCache, XCache, ecc.) Per accelerare l'elaborazione. E cache basata su memoria per sostituire un utilizzo intenso su tabelle SQL (ad es. Memcached o redis), quindi cancellare la cache non richiederebbe tempo, semplicemente svuotando la cache (ad esempio echo flush_all > /dev/tcp/127.0.0.1/11211in Bash).

In alternativa puoi sempre cancellare la cache manualmente , ad esempio:

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

Debug

Per verificare cosa sta impiegando più tempo nello specifico, è necessario eseguire il debug / il profilo (ad es. XDebug, XHProf, phpdbg, dtrace).

Su OS X / Unix, questo può essere ottenuto dtrace(dopo l'esecuzione 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); }'

Su Linux, utilizzare strace, ad es

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

Per cercare alcune cose specifiche, prova ad aggiungere ad esempio: strace ... 2>&1 | grep -C5 UPDATE.

— kenorb
fonte

5

Se si dispone di un database molto grande e il sistema funziona correttamente quando non si esegue la cancellazione della cache, è probabile che non si disponga di memoria sufficiente per supportare completamente l'installazione.

Se il tuo sito è in esecuzione su un box Linux, esegui 'top' (dalla tua shell) e premi shift-M per ordinare l'elenco dei processi in base alla memoria utilizzata. Quindi, eseguire l'operazione di cancellazione della cache da un altro terminale. Dovresti vedere mysql e apache in cima alla lista. Sarai in grado di vedere quale percentuale della memoria totale sta utilizzando ciascuno di questi processi e quanta RAM libera viene utilizzata. Se si dispone di una grande quantità di spazio virtuale, ma tutta la RAM fisica è esaurita, questa operazione potrebbe causare il blocco della memoria della VM, il che può ridurre i tempi di esecuzione a una piccola frazione di ciò che è normalmente.

Una volta, stavo gestendo un sito Drupal a metà traffico su una scatola senza abbastanza memoria sufficiente per supportare l'installazione. Quando ho eseguito la cancellazione della cache su un sito a basso traffico non correlato, la ricostruzione della cache ha spinto il sistema oltre il limite e tutto è rimasto bloccato. Quindi, il comportamento totale del sistema è importante qui; questo è il motivo per cui strumenti semplici come "top" sono un comodo punto di partenza.

— greg_1_anderson
fonte

Grazie, penso che la causa sottostante sia che il sito è in circolazione da un po 'di tempo, il db è un po' grande e il codice ha terribilmente bisogno di essere preso in considerazione. Ad esempio, un'operazione node_delete richiede circa 3 secondi. Penso che dare troppa memoria possa essere ridondante, sei d'accordo?

— awm

L'ho sulla mia macchina ed è anche lento. Ho raddoppiato la memoria, fino a 1 GB e ho cronometrato `time drush cc all`. Non molto meglio solo 4 secondi più veloce.

— awm

1

Sì, se l'intero sito è sempre lento, anche con molta memoria, cc non è il problema; dovrai fare una profilazione più generale.

— greg_1_anderson,

Inoltre, se il sito è davvero vecchio e necessita di un aggiornamento, prendi in considerazione la ricostruzione da zero con moduli nuovi e usa la migrazione da drupal a drupal ( drupal.org/project/migrate_d2d ) per spostare i tuoi contenuti.

— greg_1_anderson,

2

Non sono d'accordo (in qualche modo) con @ greg_1_anderson qui.

Se il sistema non si arresta in modo anomalo durante un cc all, quindi non penso che tu abbia un problema di memoria generale. Quando un server LAMP esaurisce la memoria, verrà eseguito lo scambio. Un server attivo che colpisce swap causerà una valanga di cattiveria. i processi httpd inizieranno ad accumularsi a causa del rallentamento del sistema (lo swap rende il sistema molto lento), il che farà sì che venga utilizzato più swap, ecc. Nei siti in cui ho visto che ciò accade, vedrei il carico di processo colpito 100, e un sacco di processi httpd attivi.

Se il tuo sistema alla fine ritorna, penso che tu sia mal sintonizzato. drush cc allcomporterà un sacco di accessi al database, quindi penso che stia mostrando di più il problema. Il mio suggerimento sarebbe di eseguire mysqltuner sul sito. Se si dispone di un database multi GB, la mia ipotesi è che il tuo innodb_buffer_pool_sizenon sia nemmeno dimensionato correttamente in remoto e che l'istanza di MySQL stia funzionando. Vorrei anche indagare su un backend della cache alternativo per cercare di ridurre l'ingombro del database.

— mpdonadio
fonte

Grazie, drupal è usato solo per l'editoria che ha uno strato servie che ne ha la vernice. Gli utenti ora arrivano a drupal. Voglio solo indagare su ciò che sta accadendo perché penso che ci sia un collo di bottiglia. Penso che la mia scommessa migliore sia attivare il registro lento mysql e monitorare il db. E poi fare un po 'di profilazione con xdebug

— awm

SHOW FULL PROCESSLIST ti dirà cosa sta succedendo senza bisogno di usare il log delle query lente (e quindi senza il riavvio del server). Vedi anche altre risposte per mytop.

— Chris Burgess,

1

Potrebbe essere il tuo ambiente di web hosting. Ti riferisci a una configurazione locale o a qualcosa di hosting su hosting condiviso o un VPS / server?

ambiente di hosting - se si utilizza l'hosting Web condiviso, la quantità di memoria che Drupal / drush può utilizzare sarà limitata, consultare: https://drupal.org/node/207036
tempo massimo di esecuzione - deve essere aumentato

— geekgirlweb
fonte

drush normalmente non è limitato da max_execution_time. Puoi fare un drush php-eval "print ini_get('max_execution_time');"doppio controllo, però.

— mpdonadio

1

Questa non è una soluzione completa, solo uno strumento in più per identificare la fonte dei tuoi ritardi.

Oltre a utilizzare topper monitorare i processi, potresti trovare l'output di mytopinformazioni. (Altre risposte sopra presuppongono MySQL ma se si utilizza un altro back-end DB, è necessario sostituire mytop con uno strumento equivalente.)

mytopesegue semplicemente MySQL SHOW FULL PROCESSLISTin un ciclo e ti mostra quali query sono in esecuzione (quindi che richiedono molto tempo). Se la pulizia della cache impiega molto tempo a ripulire questa o quella tabella, vedrai esattamente cosa sta trattenendo le cose qui. Se non hai accesso all'installazione mytop, esegui una versione grezza nella tua shell -

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

Se il ritardo non deriva dalle query MySQL, questo strumento potrebbe almeno confermarlo.

— Chris Burgess
fonte

1

Ho trovato un post sul blog intitolato Speed Up Cache Clearing su Drupal 7 per essere molto utile nel restringere precisamente quale parte del processo di cancellazione della cache rallentava le cose. I problemi che individua nel modulo caratteristiche e nel modulo API entità stavano interessando il mio sito, ma il processo dettagliato nel post mi ha anche aiutato a rintracciare i problemi che stavamo riscontrando nel nucleo Drupal e nel modulo punti di interruzione .

Ci vuole del tempo per completare il processo, ma mi ha aiutato a ridurre la cancellazione della cache da più minuti a meno di un minuto.

— Matt V.
fonte