La commande `drush cc all` prend trop de temps, que puis-je faire?

12

Sur un de mes sites, l' drush cc allexécution prend plus de 4 minutes. Le site db fait quelques Go. Cependant, je ne vois pas de raison claire pour laquelle cela prend trop de temps. Que puis-je faire pour localiser le goulot de la bouteille?

7 drush caching

— awm
source

Vérifiez le premier journal de requête mysql: drupal.stackexchange.com/questions/75629/…

— AgA

Avez-vous un cron en cours d'exécution?

— mpdonadio

Oui, j'ai un cron en cours d'exécution. Le site est lent en général. Autant de code hérité qui ne vaut pas la peine d'être refactorisé.

— awm

Je suis d'accord avec @MPD ici, je ne pense pas que ce soit lié à la mémoire. MySQL n'est également qu'une des raisons possibles. Il n'y a qu'une seule façon de le savoir et c'est de le profiler. La façon la plus simple de le faire est d'utiliser l'extension xhprof et devel, qui fonctionne également avec drush (utilisez -d pour voir le lien vers le rapport). Je suppose qu'il y a un certain nombre de problèmes, un problème typique si le site est lent pour toutes les demandes manque de modules, voir drupal.stackexchange.com/questions/724/why-is-drupal-7-so-slow . Views présente également des problèmes de performances majeurs avec les caches, voir drupal.org/node/1944674 .

— Berdir

Merci, j'ai pensé que je devais faire du profilage, mais dans le cas de la base de code drupal, il est toujours difficile de localiser le goulot d'étranglement. Bien que je dise que le site est lent, il n'est pas trop lent et drush cc all, est démesurément plus lent.

— awm

6

L'effacement du cache lui-même ne prend pas longtemps, car il s'agit simplement de tronquer les tables de cache. Ce qui prend le plus de temps, c'est de reconstruire le registre de cache après cela. Habituellement, c'est le registre de thème qui analyse tous les nouveaux crochets et tous vos dossiers Drupal pour les nouveaux fichiers de modèle, le système qui analyse les fichiers pour les nouveaux modules et les fichiers de classe, et similaires.

Vous pouvez toujours vider le cache spécifique en spécifiant drush cc theme-registryou tout autre.

Il est fortement recommandé d'utiliser le mécanisme de mise en cache PHP (par exemple OPCache, XCache, etc.) pour accélérer le traitement. Et le cache basé sur la mémoire pour remplacer une utilisation intensive sur les tables SQL (par exemple memcached ou redis), ainsi l'effacement du cache ne prendrait pas de temps, simplement en vidant le cache (par exemple echo flush_all > /dev/tcp/127.0.0.1/11211dans Bash).

Alternativement, vous pouvez toujours vider le cache manuellement , par exemple en:

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

Débogage

Pour vérifier spécifiquement ce qui prend le plus de temps, vous devez le déboguer / profiler (par exemple XDebug, XHProf, phpdbg, dtrace).

Sous OS X / Unix, cela peut être réalisé par dtrace(après l'exécution 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); }'

Sous Linux, utilisez strace, par exemple

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

Pour chercher des choses spécifiques, essayez d' ajouter par exemple: strace ... 2>&1 | grep -C5 UPDATE.

— Kenorb
source

5

Si vous disposez d'une base de données très volumineuse et que votre système fonctionne correctement lorsque vous n'effacez pas le cache, il est probable que vous ne disposiez pas de suffisamment de mémoire pour prendre pleinement en charge votre configuration.

Si votre site fonctionne sur une boîte Linux, exécutez 'top' (à partir de votre shell) et appuyez sur shift-M pour trier la liste des processus en fonction de la mémoire utilisée. Ensuite, exécutez votre opération d'effacement du cache à partir d'un autre terminal. Vous devriez voir mysql et apache monter en haut de la liste. Vous pourrez voir quel pourcentage de la mémoire totale chacun de ces processus utilise et combien de RAM libre est utilisée. Si vous avez une grande quantité d'espace virtuel, mais que toute votre RAM physique est épuisée, cette opération peut entraîner le blocage de la mémoire de la machine virtuelle, ce qui peut réduire votre temps d'exécution à une petite fraction de ce qu'il est normalement.

Une fois, j'exécutais un site Drupal à trafic moyen sur une boîte sans mémoire suffisante pour prendre en charge la configuration. Lorsque j'ai exécuté un effacement du cache sur un site à faible trafic indépendant, la reconstruction du cache a poussé le système au-delà de sa limite, et tout sauf verrouillé. Ainsi, le comportement total du système est important ici; c'est pourquoi des outils simples comme «top» sont un endroit pratique pour commencer.

— greg_1_anderson
source

Merci, je pense que la cause sous-jacente est que le site existe depuis un certain temps, la base de données est un peu grande et le code a terriblement besoin d'être refacturé. Par exemple, une opération node_delete prend environ 3 secondes. Je pense que donner trop de mémoire peut être redondant, êtes-vous d'accord?

— awm

Je l'ai sur ma machine et c'est aussi lent. J'ai doublé la mémoire, jusqu'à 1 Go et je l'ai chronométré «temps drush cc all». Pas beaucoup mieux que 4 secondes plus vite.

— awm

1

Oui, si tout le site est lent tout le temps, même avec beaucoup de mémoire, alors cc n'est pas le problème; vous devrez faire un profilage plus général.

— greg_1_anderson

De plus, si le site est vraiment ancien et a besoin d'un rafraîchissement, envisagez de reconstruire à partir de zéro avec de nouveaux modules et utilisez la migration de drupal à drupal ( drupal.org/project/migrate_d2d ) pour déplacer votre contenu.

— greg_1_anderson

2

Je vais être en désaccord (quelque peu) avec @ greg_1_anderson ici.

Si le système ne plante pas totalement pendant un cc all, alors je ne pense pas que vous ayez un problème général de mémoire. Lorsqu'un serveur LAMP manque de mémoire, il va basculer. Un serveur actif frappant l'échange provoquera une avalanche de méchanceté. Les processus httpd commenceront à s’empiler en raison du ralentissement du système (le swap rend le système très lent), ce qui entraînera plus d’échanges, etc. Sur les sites où j’ai vu cela se produire, je verrais la charge du processus atteindre 100, et une tonne de processus httpd actifs.

Si votre système finit par revenir, je pense que vous êtes mal réglé. drush cc allentraînera de nombreux accès à la base de données, donc je pense que cela montre davantage le problème. Ma suggestion serait d'exécuter mysqltuner sur le site. Si vous avez une base de données de plusieurs Go, je suppose que votre innodb_buffer_pool_sizetaille n'est même pas à distance correctement et que votre instance MySQL est débordante. J'enquêterais également sur un autre backend de cache pour essayer de réduire l'empreinte de la base de données.

— mpdonadio
source

Merci, drupal est utilisé uniquement pour une utilisation avec un éditeur qui a une couche de service qui a du vernis. Les utilisateurs ont désormais accès à drupal. Je veux juste enquêter sur ce qui se passe parce que je pense qu'il y a un goulot d'étranglement. Je pense que mon meilleur pari est d'activer le journal lent mysql et de surveiller la base de données. Et puis faites du profilage avec xdebug

— awm

SHOW FULL PROCESSLIST vous dira ce qui se passe sans avoir besoin d'utiliser un journal de requête lent (et donc sans redémarrage du serveur). Voir aussi l'autre réponse pour mytop.

— Chris Burgess

1

Il pourrait s'agir de votre environnement d'hébergement Web. Faites-vous référence à une configuration locale, ou quelque chose d'hébergement sur un hébergement partagé ou un VPS / serveur?

environnement d'hébergement - si vous êtes sur un hébergement Web partagé, la quantité de mémoire que Drupal / drush peut utiliser sera limitée, voir: https://drupal.org/node/207036
temps d'exécution max - doit être augmenté

— geekgirlweb
source

drush n'est normalement pas limité par max_execution_time. Vous pouvez faire drush php-eval "print ini_get('max_execution_time');"une double vérification, cependant.

— mpdonadio

1

Ce n'est pas une solution complète, juste un outil de plus pour aider à identifier la source de vos retards.

En plus d'utiliser toppour surveiller les processus, vous pouvez trouver la sortie mytopinformative. (Les autres réponses ci-dessus supposent MySQL mais si vous utilisez un autre backend DB, vous devrez échanger mytop contre un outil équivalent.)

mytopexécute simplement MySQL SHOW FULL PROCESSLISTen boucle, et vous montre quelles requêtes sont exécutées (donc qui prennent beaucoup de temps). Si le cache vide prend du temps à nettoyer telle ou telle table, vous verrez exactement ce qui retient les choses ici. Si vous n'avez pas accès à l'installation mytop, faites simplement une version brute dans votre shell -

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

Si le retard ne provient pas de requêtes MySQL, cet outil peut au moins le confirmer pour vous.

— Chris Burgess
source

1

J'ai trouvé un article de blog intitulé Accélérer l'effacement du cache sur Drupal 7 pour être très utile pour préciser précisément quelle partie du processus d'effacement du cache ralentissait les choses. Les problèmes qu'il identifie dans le module de fonctionnalités et le module API d'entité affectaient mon site, mais le processus détaillé dans le message m'a également aidé à localiser les problèmes que nous rencontrions dans le module de base et de points d'arrêt Drupal .

Cela prend un certain temps pour travailler à travers le processus, mais cela m'a aidé à réduire les vides de cache de plusieurs minutes à moins d'une minute.

— Matt V.
source