Кеш Magento 2.2.x відключається автоматично

Перш за все, я не міг знайти жодної інформації про подібні проблеми в Інтернеті.

У нас є виробниче середовище з інтеграцією git . Ми вносимо свої зміни до нього лише за допомогою git ( git pull ).

Проблема полягає в тому, що якимось чином в одному з кроків кеш Magento відключається автоматично (усі нулі при перевірці кешу: статус) . Це спричиняє проблему, якщо це пропущено через програміста, що додатково спричиняє перевантаження сервера через велику трафіку, що 'трапиться' в Magento без кешу.

Може, хтось із вас бачив цю проблему раніше? Ми не знаємо, коли або як саме це відбувається.
І це ніби з'являється випадковим чином.

Звичайні кроки, які ми робимо:

• уможливлення технічного обслуговування
• git pull
• встановлення композитора (за потреби)
• модуль включення Vendor_ModuleName (за потреби)
• налаштування: оновлення (за потреби)
• очищення статичних речей
• команда розгортання
• очищення схованок
• очищення opcache
• відключення технічного обслуговування

Буду вдячний за будь-які цінні пропозиції, які могли б допомогти вирішити подібне питання.

Це виглядає як відома проблема .
Це час від часу трапляється над проектом, над яким я працюю, але мені не вдалося знайти кроки для відтворення. Все, що я можу сказати, - це відбувається під час процесу розгортання.
Все, що я міг знайти, - це те, що за певних обставин файл .regenerateзаписується в varпапку (або під час оновлення установки, або при встановленні / модернізації композитора), і якщо цей файл присутній під час запуску setup:di:compileкешу, вимкнено та відновлюється після завершення процесу компіляції.
Чомусь кеш іноді не вмикається повторно.
Ми скористалися швидким та брудним підходом та зробили php bin/magento cache:enableвпевненим останній крок процесу розгортання . Так в основному ми заховали бруд під килим.

Ви можете знайти код, який відключає кеш-пам'ять. Тут
він загорнутий у TODO: removeвиписку.

Для всіх, хто цікавиться, я думаю, що я можу прояснити це питання. Схоже, це проблема сумісності (умови гонки) в \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, коли встановлено прапор var / .regenerate, і більше одного процесу / запиту намагається очистити створені файли .

Ймовірніше, що це станеться, коли у вас включений cron, і багато груп cron, що використовують config_separate_process config. Коли більше одного процесу намагаються очистити одне і те ж, FileIterator не працює з різними повідомленнями, схожими на: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.

Перехід до виклику $this->write->delete(self::REGENERATE_FLAG);, відразу після перевірки наявності прапора, вирішує проблему, оскільки перший процес, що надходить, вважає себе відповідальним за очищення файлів.

Я залишаю тут демонстраційне відео про те, як повторити проблему : https://youtu.be/9-X1cIIY7y8

І сценарій, використаний для цього:

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