Cache Magento 2.2.x désactivé automatiquement

16

Tout d'abord, je n'ai trouvé aucune information sur ce type de problème sur le Web.

Nous avons un environnement de production avec intégration git . Nous ne tirons nos modifications que via git ( git pull ).

Le problème est que, d'une manière ou d'une autre, dans l'une des étapes, les caches Magento se désactivent automatiquement (tous les zéros lors de la vérification du cache: état) . Cela provoque un problème si cela est manqué via le programmateur, ce qui entraîne une surcharge du serveur en raison du trafic important vers le Magento sans cache.

Peut-être que certains d'entre vous ont déjà vu ce problème? Nous ne savons pas quand ni comment cela se produit exactement.
Et cela apparaît un peu au hasard.

Étapes habituelles que nous effectuons:

  • permettre la maintenance
  • git pull
  • installation du compositeur (si nécessaire)
  • module enable Vendor_ModuleName (si nécessaire)
  • configuration: mise à niveau (si nécessaire)
  • effacement des éléments statiques
  • commande de déploiement
  • effacement des caches
  • effacer opcache
  • désactivation de la maintenance

J'apprécierais toute suggestion utile qui pourrait aider à résoudre ce type de problème.

Macas
la source
Si vous faites cela, le setup:upgradecache se désactivera automatiquement
Amit Bera
@AmitBera Je dois être en désaccord avec vous, même si j'interrompt ce commant, cela ne fermera pas le cache
Macas
D'accord. Je vais faire un test .... voir check screnerio
Amit Bera

Réponses:

16

Cela ressemble à un problème connu :
cela se produit de temps en temps sur le projet sur lequel je travaille, mais je n'ai pas pu trouver les étapes à reproduire. Tout ce que je peux dire, c'est que cela se produit lors d'un processus de déploiement.
Tout ce que j'ai pu trouver, c'est que dans certaines circonstances, un fichier .regenerateest écrit dans le vardossier (lors de la mise à niveau de l'installation ou de l'installation / mise à niveau du compositeur) et si ce fichier est présent lors de l'exécution setup:di:compiledu cache est désactivé et réactivé lorsque le processus de compilation est terminé.
Pour une raison quelconque, le cache n'est parfois pas réactivé.
Nous avons adopté une approche rapide et sale et avons fait la dernière étape du processus de déploiement php bin/magento cache:enablepour être sûr. Donc, fondamentalement, nous avons caché la saleté sous le tapis.

Vous pouvez trouver le code qui désactive le cache ici
Il est encapsulé dans une TODO: removeinstruction.

Marius
la source
1
peut confirmer. le cacher sous un tapis quand il se produit
Philipp Sander
Ok, on dirait que je ne suis pas le seul avec ça. Nous obtenons généralement cela lorsqu'une erreur se produit et que le processus de déploiement se bloque. En regardant vos informations, ce sera le cas. Merci pour l'info, en marquant celle-ci comme une réponse.
Macas
Quelqu'un a-t-il obtenu la solution?
Manish Goswami
5

Pour toute personne intéressée, je pense que je peux apporter un peu de lumière sur cette question. Il semble s'agir d'un problème de concurrence (condition de concurrence critique) dans \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, lorsque l'indicateur var / .regenerate est défini et que plusieurs processus / demandes essaient de nettoyer les fichiers générés .

Il est plus probable que cela se produise lorsque cron est activé et que de nombreux groupes cron utilisent la configuration use_separate_process. Lorsque plusieurs processus tentent de nettoyer le même, FileIterator échoue avec différents messages similaires à:FilesystemIterator::__construct(/Users/adrianmartinez/Sites/r2-project-develop-b2b/environments/2-2-develop-b2b/magento/generated/code): failed to open dir: No such file or directory.

Passer à l'appel $this->write->delete(self::REGENERATE_FLAG);, juste après la vérification de l'existence d'un indicateur, résout le problème, car le premier processus arrivant se marque comme responsable du nettoyage des fichiers.

Je laisse ici une vidéo de démonstration sur la façon de reproduire le problème : https://youtu.be/9-X1cIIY7y8

Et le script utilisé pour cela:

#!/bin/bash

# \Magento\Framework\Code\GeneratedFiles has a concurrency problem
# Create regenerate flag and launch parallel commands that try to regenerate at the same time
# This is a real case, cron:run launches stand alone processes in parallel

# Created by magento composer installer upon code install or module enable/disable
touch var/.regenerate

# Launch parallel commands
# Error differs each execution, sometimes it even works
bin/magento cron:run --group=ddg_automation --bootstrap=standaloneProcessStarted=1 2>&1 &
bin/magento cron:run --group=index --bootstrap=standaloneProcessStarted=1 2>&1 &

wait
echo "All done"
Adrián Martínez Guantes
la source
Avez-vous trouvé la solution ?
Manish Goswami
J'ai trouvé comment reproduire ce problème mais pas la solution. github.com/magento/magento2/issues/17634
Manish Goswami