Cache Magento 2.2.x disabilitata automaticamente

Prima di tutto, non sono riuscito a trovare informazioni su questo tipo di problema in nessuna parte del Web.

Abbiamo un ambiente di produzione con integrazione git . Inseriamo le modifiche solo tramite git ( git pull ).

Il problema è che, in qualche modo in uno dei passaggi, la cache di Magento si disattiva automaticamente (tutti gli zeri durante il controllo della cache: stato) . Ciò causa un problema se questo viene perso tramite il programmatore, causando un ulteriore sovraccarico del server a causa dell'elevato traffico 'bashing' verso Magento senza cache.

Forse alcuni di voi hanno già visto questo problema? Non sappiamo quando o come accada esattamente.
E sembra un po 'a caso.

I soliti passi che facciamo:

• consentire la manutenzione
• git pull
• installazione del compositore (se necessario)
• modulo abilita Vendor_ModuleName (se necessario)
• setup: upgrade (se necessario)
• cancellare roba statica
• comando di distribuzione
• svuotare le cache
• eliminazione di opcache
• disabilitazione della manutenzione

Gradirei preziosi suggerimenti che potrebbero aiutare a risolvere questo tipo di problema.

Sembra un problema noto :
questo succede di tanto in tanto sul progetto a cui sto lavorando, ma non sono riuscito a trovare i passaggi per riprodurlo. Tutto quello che posso dire è che succede durante un processo di distribuzione.
Tutto ciò che ho potuto trovare è che in determinate circostanze un file .regenerateviene scritto nella varcartella (all'aggiornamento dell'installazione o all'installazione / aggiornamento del compositore) e se quel file è presente durante l'esecuzione setup:di:compiledella cache è disabilitato e riattivato al termine del processo di compilazione.
Per qualche motivo, a volte la cache non viene riattivata.
Abbiamo adottato un approccio rapido e sporco e abbiamo php bin/magento cache:enableassicurato l'ultimo passaggio del processo di distribuzione . Quindi praticamente abbiamo nascosto la terra sotto il tappeto.

Puoi trovare il codice che disabilita la cache qui
È racchiuso in TODO: removeun'istruzione.

Per chiunque sia interessato, penso di poter far luce su questo problema. Sembra essere un problema di concorrenza (race condition) in \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, quando è impostato il flag var / .regenerate e più di un processo / richiesta tenta di pulire i file generati .

È più probabile che accada quando hai abilitato cron e molti gruppi cron che usano la configurazione use_separate_process. Quando più di un processo tenta di pulire lo stesso, FileIterator ha esito negativo con diversi messaggi simili a: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.

Passando alla chiamata $this->write->delete(self::REGENERATE_FLAG);, subito dopo il controllo dell'esistenza del flag si risolve il problema, poiché il primo processo in arrivo si contrassegna come responsabile della pulizia dei file.

Lascio qui un video dimostrativo su come replicare il problema : https://youtu.be/9-X1cIIY7y8

E lo script usato per questo:

#!/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"