Bộ nhớ cache Magento 2.2.x tự động bị tắt

Trước hết, tôi không thể tìm thấy bất kỳ thông tin nào về loại vấn đề này ở bất cứ đâu trên web.

Chúng tôi có một môi trường sản xuất với tích hợp git . Chúng tôi chỉ thay đổi thông qua git ( git pull ).

Vấn đề là, bằng cách nào đó, trong một trong các bước, Magento lưu trữ tự động vô hiệu hóa (tất cả các số không khi kiểm tra bộ đệm: trạng thái) . Điều đó gây ra sự cố nếu điều này bị bỏ qua thông qua lập trình viên, gây ra tình trạng quá tải máy chủ do lưu lượng truy cập cao 'bash' vào Magento mà không có bộ đệm.

Có lẽ một số bạn đã thấy vấn đề này trước đây? Chúng tôi không biết chính xác nó xảy ra khi nào hoặc như thế nào.
Và nó xuất hiện ngẫu nhiên.

Các bước thông thường chúng tôi làm:

• cho phép bảo trì
• kéo git
• cài đặt nhà soạn nhạc (nếu cần)
• mô-đun kích hoạt Vendor_ModuleName (nếu cần)
• thiết lập: nâng cấp (nếu cần)
• dọn dẹp công cụ tĩnh
• lệnh triển khai
• xóa bộ nhớ cache
• xóa opcache
• vô hiệu hóa bảo trì

Tôi sẽ đánh giá cao bất kỳ đề xuất có giá trị nào có thể giúp giải quyết loại vấn đề này.

Điều này có vẻ như là một vấn đề đã biết :
Điều này thỉnh thoảng xảy ra với dự án tôi đang thực hiện, nhưng tôi không thể tìm thấy các bước để tái tạo. Tất cả những gì tôi có thể nói là nó xảy ra trong quá trình triển khai.
Tất cả những gì tôi có thể tìm thấy là trong một số trường hợp, một tệp .regenerateđược ghi trong varthư mục (khi cài đặt nâng cấp hoặc cài đặt / nâng cấp trình soạn thảo) và nếu tệp đó xuất hiện khi chạy setup:di:compilebộ đệm thì bị tắt và bật lại khi quá trình biên dịch kết thúc.
Vì một số lý do, đôi khi bộ đệm không được kích hoạt lại.
Chúng tôi đã thực hiện cách tiếp cận nhanh chóng và bẩn thỉu và thực hiện bước cuối cùng của quy trình triển khai php bin/magento cache:enableđể chắc chắn. Vì vậy, về cơ bản, chúng tôi giấu bụi bẩn dưới tấm thảm.

Bạn có thể tìm thấy mã vô hiệu hóa bộ đệm trong đây
Nó được gói trong một TODO: removecâu lệnh.

Đối với bất cứ ai quan tâm, tôi nghĩ rằng tôi có thể mang lại một chút ánh sáng về vấn đề này. Đây có vẻ là một vấn đề đồng thời (điều kiện chủng tộc) trong \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, khi cờ var / .regenerate được đặt và nhiều hơn một quy trình / yêu cầu cố gắng xóa các tệp được tạo .

Nó có nhiều khả năng xảy ra khi bạn bật cron và nhiều nhóm cron sử dụng config_separate_ process config. Khi có nhiều hơn một quá trình đang cố gắng làm sạch giống nhau, FileIterator sẽ thất bại với các thông báo khác nhau tương tự như: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.

Chuyển lên cuộc gọi đến $this->write->delete(self::REGENERATE_FLAG);, ngay sau khi kiểm tra sự tồn tại của cờ giải quyết vấn đề, vì quá trình đến đầu tiên đánh dấu chính nó là trách nhiệm làm sạch các tệp.

Tôi để lại ở đây một video demo về cách tái tạo vấn đề : https://youtu.be/9-X1cIIY7y8

Và tập lệnh được sử dụng cho nó:

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