Magento 2.2.x कैश स्वचालित रूप से अक्षम हो गया

16

सबसे पहले, मैं वेब पर कहीं भी इस तरह के मुद्दे के बारे में कोई जानकारी नहीं पा सकता हूं।

हमारे पास गिट एकीकरण के साथ उत्पादन का माहौल है । हम अपने परिवर्तनों को केवल गिट ( git पुल ) के माध्यम से खींचते हैं ।

समस्या यह है कि, किसी भी एक चरण में Magento कैश स्वचालित रूप से अक्षम हो जाता है (कैश की जाँच करते समय सभी शून्य: स्थिति) । यह एक समस्या का कारण बनता है अगर यह प्रोग्रामर के माध्यम से याद किया जाता है, जिससे कैश के बिना Magento के लिए उच्च ट्रैफ़िक 'कोशिंग' के कारण सर्वर ओवरलोड होता है।

हो सकता है कि आप में से कुछ ने पहले इस मुद्दे को देखा हो? हमें नहीं पता कि यह वास्तव में कब या कैसे होता है।
और यह थोड़े बेतरतीब ढंग से प्रकट होता है।

सामान्य कदम हम करते हैं:

रखरखाव सक्षम करना
पकड़ खींचो
संगीतकार स्थापित करें (यदि आवश्यक हो)
मॉड्यूल Vendor_ModuleName सक्षम करें (यदि आवश्यक हो)
सेटअप: उन्नयन (यदि आवश्यक हो)
स्थिर सामान साफ़ करना
परिनियोजन आदेश
क्लीयरिंग कैश
समाशोधन
रखरखाव अक्षम करना

मैं किसी भी मूल्यवान सुझाव की सराहना करूंगा जो इस तरह के मुद्दे को हल करने में मदद कर सकता है।

magento2 magento2.2 cache

— मकस
स्रोत

यदि आप करते हैं setup:upgradeतो कैश automaticallyu को निष्क्रिय कर देगा

— अमित बेरा

@AmitBera मुझे आपसे असहमत होना चाहिए, भले ही मैंने इस कमेंट को इंटरप्ट किया हो, यह कैश की बारी नहीं होगी

— मैकास

ठीक है। मैं परीक्षण करना होगा .... जांच screnerio देख

— अमित बेरा

16

यह एक ज्ञात मुद्दे की तरह दिखता है :
यह उस परियोजना पर समय-समय पर होता है जिस पर मैं काम कर रहा हूं, लेकिन मैं पुन: पेश करने के चरणों को खोजने में सक्षम नहीं था। मैं केवल इतना कह सकता हूं कि यह तैनाती की प्रक्रिया के दौरान होता है।
मैं यह पा सकता हूं कि कुछ परिस्थितियों में एक फ़ाइल फ़ोल्डर .regenerateमें लिखी जाती है var(या तो सेटअप अपग्रेड या कंपोज़र इंस्टाल / अपग्रेड में) और यदि वह फ़ाइल मौजूद है तो setup:di:compileकैश को अक्षम किया जाता है और संकलन प्रक्रिया समाप्त होने पर फिर से सक्षम किया जाता है।
किसी कारण से, कभी-कभी कैश को फिर से सक्षम नहीं किया जाता है।
हमने त्वरित और गंदा तरीका अपनाया और php bin/magento cache:enableयह सुनिश्चित करने के लिए परिनियोजन प्रक्रिया का अंतिम चरण बनाया । तो मूल रूप से हम गंदगी गलीचा के नीचे छिपा दिया।

आप उस कोड को ढूंढ सकते हैं जो यहां कैश को निष्क्रिय करता है ।
यह एक TODO: removeस्टेटमेंट में लिपटा हुआ है ।

— Marius
स्रोत

1

पुष्टि कर सकते हैं। जब यह होता है तो इसे गलीचा के नीचे छिपा दिया जाता है

— फिलिप सैंडर

ठीक है, ऐसा लगता है कि मैं केवल यही नहीं हूं। हमें आमतौर पर यह तब मिलता है जब कोई त्रुटि होती है और परिनियोजन प्रक्रिया क्रैश हो जाती है। आपकी जानकारी को देखकर, यह मामला होगा। जानकारी के लिए धन्यवाद, इसे एक उत्तर के रूप में चिह्नित करना।

— मैकास

क्या किसी को इसका हल मिला?

— मनीष गोस्वामी

5

रुचि रखने वाले किसी के लिए, मुझे लगता है कि मैं इस मुद्दे के बारे में कुछ प्रकाश डाल सकता हूं। लगता है कि यह एक संगामिति (दौड़ की स्थिति) की समस्या है \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, जब var / .regenerate ध्वज सेट किया जाता है, और एक से अधिक प्रक्रिया / अनुरोध जनरेट की गई फ़ाइलों को साफ़ करने का प्रयास करता है ।

जब आप क्रोन सक्षम होते हैं, और कई क्रोन समूहों का उपयोग करने की संभावना होती है, तो use_separate_process कॉन्फ़िगरेशन का उपयोग करना। जब एक से अधिक प्रक्रिया एक ही को साफ करने की कोशिश कर रहे हैं, तो 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"

— एड्रियन मार्टिनेज़ गैंटेस
स्रोत

क्या आपको इसका हल मिला?

— मनीष गोस्वामी

मैंने पाया कि इस मुद्दे को कैसे पुन: पेश किया जाए लेकिन समाधान नहीं मिला। github.com/magento/magento2/issues/17634

— मनीष गोस्वामी