Magento 2.2.x önbelleği otomatik olarak devre dışı bırakıldı

Her şeyden önce, web üzerinde hiçbir yerde bu tür bir konu hakkında herhangi bir bilgi bulamadım.

Git entegrasyonu ile bir üretim ortamımız var . Değişikliklerimizi sadece git ( git pull ) ile alıyoruz .

Sorun şu ki, bir şekilde Magento önbellek adımlarından birinde otomatik olarak devre dışı bırakılır (önbellek: durum kontrol edilirken tüm sıfırlar) . Bu programcı tarafından kaçırılırsa, önbellek olmadan Magento yüksek trafik 'dayak' nedeniyle sunucu aşırı yük neden olur, bu bir soruna neden olur.

Belki bazılarınız bu sorunu daha önce görmüşsünüzdür? Tam olarak ne zaman veya nasıl gerçekleştiğini bilmiyoruz.
Ve biraz rastgele görünüyor.

Her zamanki adımlarımız:

• bakım sağlama
• git çekme
• besteci kurulumu (gerekirse)
• modül etkin Vendor_ModuleName (gerekirse)
• kurulum: yükseltme (gerekirse)
• statik şeyleri temizleme
• dağıtım komutu
• önbellek temizleme
• temizleme opcache
• bakımı devre dışı bırakma

Bu tür bir sorunun çözülmesine yardımcı olabilecek değerli önerileri takdir ediyorum.

Bu bilinen bir soruna benziyor :
Bu, üzerinde çalıştığım projede zaman zaman oluyor, ancak çoğaltma adımlarını bulamadım. Söyleyebileceğim tek şey bir dağıtım işlemi sırasında oluyor.
Tüm bulabildiğim belirli koşullar altında bir dosya (kurulum yükseltme veya besteci yükleme / yükseltme) klasöründe .regenerateyazılmış ve önbellek varçalıştırılırken bu dosya varsa setup:di:compiledevre dışı bırakılır ve derleme işlemi bittiğinde yeniden etkinleştirilir.
Bazı nedenlerden dolayı, bazen önbellek yeniden etkinleştirilmez.
Hızlı ve kirli bir yaklaşım izledik ve dağıtım sürecinin son adımını php bin/magento cache:enableemin olmak için yaptık . Yani temelde kiri halının altına sakladık.

Önbelleği devre dışı bırakan kodu burada bulabilirsiniz
. Bir TODO: removedeyime sarılmıştır .

İlgilenen herkes için bence bu konuya ışık tutabilirim. Var / .regenerate bayrağı ayarlandığında ve birden fazla işlem / istek oluşturulan dosyaları temizlemeye çalıştığında \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles içinde bir eşzamanlılık (yarış koşulu) sorunu gibi görünüyor .

Cron'u etkinleştirdiğinizde ve use_separate_process config kullanan birçok cron grubunun gerçekleşmesi daha olasıdır. Birden fazla işlem aynı şeyi temizlemeye çalıştığında, FileIterator aşağıdakine benzer farklı iletilerle başarısız olur: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);Bayrak varlığından hemen sonra çağrıyı taşımak sorunu çözer, çünkü ilk gelen işlem dosyaları temizlemekten sorumlu olarak işaretler.

Burada sorunun nasıl kopyalanacağı hakkında bir demo video bırakıyorum : https://youtu.be/9-X1cIIY7y8

Ve bunun için kullanılan komut dosyası:

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