Pamięć podręczna Magento 2.2.x jest automatycznie wyłączana

Po pierwsze, nie mogłem znaleźć żadnych informacji na temat tego rodzaju problemów w Internecie.

Mamy środowisko produkcyjne z integracją git . Wyciągamy nasze zmiany tylko za pomocą git ( git pull ).

Problem polega na tym, że w jakiś sposób w jednym z kroków pamięci podręczne Magento wyłączają się automatycznie (wszystkie zera podczas sprawdzania pamięci podręcznej: status) . Powoduje to problem, jeśli zostanie to pominięte przez programator, co dodatkowo powoduje przeciążenie serwera z powodu „uderzenia” dużego ruchu w Magento bez pamięci podręcznej.

Może niektórzy z was widzieli już ten problem? Nie wiemy, kiedy i jak to się dokładnie dzieje.
I to wydaje się przypadkowe.

Zwykłe kroki, które wykonujemy:

• umożliwiający konserwację
• git pull
• instalacja kompozytora (w razie potrzeby)
• włącz moduł Vendor_ModuleName (w razie potrzeby)
• setup: upgrade (w razie potrzeby)
• usuwanie statycznych rzeczy
• polecenie wdrożenia
• czyszczenie pamięci podręcznej
• czyszczenie opcache
• wyłączanie konserwacji

Byłbym wdzięczny za wszelkie cenne sugestie, które mogłyby pomóc w rozwiązaniu tego rodzaju problemu.

Wygląda to na znany problem :
zdarza się to od czasu do czasu nad projektem, nad którym pracuję, ale nie byłem w stanie znaleźć kroków do odtworzenia. Mogę tylko powiedzieć, że dzieje się to podczas procesu wdrażania.
Jedyne, co mogłem znaleźć, to to, że w pewnych okolicznościach plik .regeneratejest zapisywany w varfolderze (podczas aktualizacji instalatora lub instalacji / aktualizacji kompozytora) i jeśli plik ten jest obecny podczas uruchamiania setup:di:compilepamięci podręcznej, jest wyłączany i włączany ponownie po zakończeniu procesu kompilacji.
Z jakiegoś powodu czasami pamięć podręczna nie jest ponownie włączana.
Przyjęliśmy szybkie i brudne podejście i php bin/magento cache:enabledla pewności zrobiliśmy ostatni krok procesu wdrażania . Zasadniczo schowaliśmy brud pod dywanikiem.

Można znaleźć kod, który wyłącza pamięć podręczną w tutaj
jest owinięta w TODO: removeoświadczeniu.

Dla wszystkich zainteresowanych myślę, że mogę wnieść nieco światła na ten temat. Wydaje się, że jest to problem współbieżności (warunku wyścigu) w \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, gdy ustawiona jest flaga var / .regenerate, i więcej niż jeden proces / żądanie próbuje wyczyścić wygenerowane pliki .

Jest to bardziej prawdopodobne, gdy masz włączone cron i wiele grup cron używa konfiguracji use_separate_process. Gdy więcej niż jeden proces próbuje wyczyścić to samo, FileIterator kończy się niepowodzeniem z różnymi komunikatami podobnymi do: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.

Przeniesienie wywołania do $this->write->delete(self::REGENERATE_FLAG);, tuż po sprawdzeniu istnienia flagi rozwiązuje problem, ponieważ pierwszy nadchodzący proces określa się jako odpowiedzialny za czyszczenie plików.

Zostawiam tutaj film demonstracyjny o tym, jak odtworzyć problem : https://youtu.be/9-X1cIIY7y8

I użyty do tego skrypt:

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