सीधे कंटेंट पर जाएं
Configuration

WordPress में "Allowed Memory Size Exhausted" कैसे ठीक करें

अगर आपकी साइट पर Fatal error: Allowed memory size of 268435456 bytes exhausted दिख रहा है, तो wp-config.php में / That's all, stop editing! / के ऊपर यह लाइन जोड़ें

Published

अगर आपकी साइट पर Fatal error: Allowed memory size of 268435456 bytes exhausted दिख रहा है, तो wp-config.php में /* That's all, stop editing! */ कमेंट के ऊपर यह लाइन जोड़ें: define( 'WP_MEMORY_LIMIT', '256M' );। इससे ज़्यादातर साइटें एक मिनट के अंदर वापस ऑनलाइन आ जाती हैं। लेकिन जाने से पहले इस पूरे पेज को पढ़ लें, क्योंकि लिमिट बढ़ाना एक डायग्नोसिस है, इलाज नहीं। अगर क्रैश किसी बड़े नंबर पर वापस आ जाता है, तो असली दिक्कत वह कोड है जो बिना किसी सीमा के मेमोरी खा रहा है, और बड़ी सीलिंग उसे बस और खुली छूट दे देती है।

इस एरर का असल में मतलब क्या है

PHP यह ट्रैक करता है कि हर रिक्वेस्ट ने कितनी मेमोरी अलॉकेट की है। जब कोई एक रिक्वेस्ट php.ini में सेट (या WordPress द्वारा ओवरराइड) memory_limit से ज़्यादा अलॉकेट करने की कोशिश करती है, तो PHP उस रिक्वेस्ट को तुरंत एक fatal error के साथ मार देता है और जिस बाइट काउंट पर वह मरी वह प्रिंट कर देता है। 268435456 bytes यानी 256M। 134217728 यानी 128M। 536870912 यानी 512M। “tried to allocate” के बाद का नंबर आपको आख़िरी तिनके का साइज़ बताता है, समस्या का साइज़ नहीं।

WordPress अपनी अलग लिमिट PHP के ऊपर लगाता है। WP_MEMORY_LIMIT (डिफ़ॉल्ट 40M, या इससे ज़्यादा हो तो PHP की लिमिट) फ्रंट एंड को कंट्रोल करता है। WP_MAX_MEMORY_LIMIT (डिफ़ॉल्ट 256M) एडमिन-साइड ऑपरेशन जैसे media library और plugin अपडेट को कंट्रोल करता है, जिन्हें सचमुच ज़्यादा मेमोरी चाहिए होती है। WordPress लोड होने पर इन कॉन्स्टेंट के आधार पर ini_set('memory_limit', ...) कॉल करता है — लेकिन सिर्फ़ तभी जब आपका होस्ट ini_set की इजाज़त देता हो, और सिर्फ़ उस हार्ड कैप तक जो आपका होस्ट सेट करता है। यह आख़िरी बात ही वजह है कि wp-config.php एडिट करने से कभी-कभी कुछ होता ही नहीं दिखता।

इसे ठीक करें, इसी क्रम में

1. wp-config.php में WordPress की लिमिट बढ़ाएं। सबसे पहले यही आज़माना चाहिए क्योंकि यह रिवर्सिबल है और किसी और चीज़ को नहीं छूता।

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

अगर आपको यक़ीन नहीं है कि ये लाइनें कहाँ जाती हैं या आप एक साथ बाक़ी सामान्य कॉन्स्टेंट भी सही तरीके से सेट करना चाहते हैं, तो हमारा wp-config generator एक साफ़-सुथरा ब्लॉक बना देता है जिसे आप पेस्ट कर सकते हैं। जगह मायने रखती है — “stop editing” लाइन के नीचे कुछ भी हो, वह इग्नोर कर दिया जाता है।

2. अगर इससे कुछ नहीं होता, तो आपका होस्ट PHP को कैप कर रहा है। memory_limit को PHP लेवल पर बढ़ाएं। php.ini में:

memory_limit = 256M

कई shared hosts पर आप php.ini को सीधे एडिट नहीं कर सकते। इसके बजाय अपने web root में .user.ini फ़ाइल आज़माएं, या Apache/mod_php सेटअप पर इसे .htaccess के ज़रिए सेट करें:

php_value memory_limit 256M

ध्यान दें कि .htaccess में php_value nginx या PHP-FPM सेटअप पर 500 error देता है, क्योंकि यह एक Apache/mod_php डायरेक्टिव है। अगर इसे जोड़ने के बाद 500 आता है, तो वजह यही है — इसे हटा दें और .user.ini का इस्तेमाल करें।

3. जो वैल्यू असल में लाइव है उसकी पुष्टि करें। आपने जो एडिट किया उस पर भरोसा मत कीजिए; भरोसा उस पर कीजिए जो PHP बता रहा है। अपने web root में एक एक-लाइन की फ़ाइल रखें:

<?php echo ini_get('memory_limit');

इसे ब्राउज़र में लोड करें, वैल्यू पढ़ें, फिर फ़ाइल डिलीट कर दें। अगर 256M सेट करने के बाद भी यह 128M दिखा रहा है, तो आपका होस्ट आपको ओवरराइड कर रहा है और आपको उनसे संपर्क करना होगा या उनकी कंट्रोल पैनल सेटिंग इस्तेमाल करनी होगी।

वह हिस्सा जो ज़्यादातर गाइड छोड़ देती हैं

लिमिट बढ़ाना डायग्नोसिस है। यहाँ बताया गया है कि नतीजे को कैसे पढ़ें।

अगर आपने 256M सेट किया और साइट सामान्य ट्रैफ़िक में ठीक चलती रहती है, तो आपकी सीलिंग सचमुच बहुत कम थी — यह उन साइटों पर आम है जिनमें बड़ी media library, WooCommerce, या page builder होते हैं। आपका काम हो गया।

अगर आपने 256M सेट किया और यह फिर क्रैश हुई, फिर 512M किया और फिर क्रैश हुई, तो इसे बढ़ाना बंद करें। एक सामान्य WordPress रिक्वेस्ट को 512M की ज़रूरत नहीं होती। जब मेमोरी का इस्तेमाल बिना किसी सीलिंग के चढ़ता रहता है, तो कुछ लूप में है या जमा हो रहा है: कोई plugin पूरी डेटाबेस टेबल को एक array में लोड कर रहा है, कोई add_action जो खुद को बार-बार रिकर्सिवली ट्रिगर करता है, कोई import रूटीन जो हर row को एक साथ मेमोरी में रखे हुए है, या एक ही hook के अंदर दो plugin आपस में भिड़ रहे हैं। लिमिट बढ़ाने से बिना सीमा वाला लूप ठीक नहीं होता — यह बस क्रैश को कुछ सेकंड आगे खिसका देता है और उसे दोबारा पैदा करना और मुश्किल बना देता है।

गुनहगार को ढूँढने के लिए, सारे plugins डिएक्टिवेट कर दें और Twenty Twenty-Four जैसी डिफ़ॉल्ट theme पर स्विच कर दें। अगर एरर रुक जाता है, तो एक-एक करके फिर से एक्टिवेट करें जब तक वह वापस न आ जाए। जहाँ यह मरता है वहाँ पकड़ने के लिए debug log ऑन करें:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

wp-content/debug.log में fatal लाइन उस फ़ाइल और लाइन नंबर का नाम बताती है जिसने आख़िरी चंक अलॉकेट किया। वही आमतौर पर लूप होता है, या उससे एक फ़ंक्शन कॉल की दूरी पर होता है।

क्या नहीं करना चाहिए

WP_MEMORY_LIMIT को -1 या 1024M पर सेट करके भूल मत जाइए। अनलिमिटेड मेमोरी किसी leak को ठीक नहीं करती; यह एक बेकाबू रिक्वेस्ट को पूरा सर्वर खा जाने देती है, जिससे उसी बॉक्स पर मौजूद बाक़ी हर साइट डाउन हो सकती है और आपको अपने होस्ट का फ़ोन आ सकता है। सीलिंग एक सेफ़्टी फ़ीचर है। एक रखिए ज़रूर।

ini_set('memory_limit', '512M') को प्राइमरी फ़िक्स के तौर पर functions.php में पेस्ट मत कीजिए। कुछ फ़ेल्योर के लिए यह बहुत देर से चलता है — अगर क्रैश WordPress core लोड होने के दौरान, आपकी theme के functions.php के चलने से पहले होता है, तो वह लाइन कभी चलती ही नहीं। wp-config.php पहले लोड होता है और यही सही जगह है।

यह मत मान लीजिए कि यह होस्टिंग की समस्या है और अपना प्लान अपग्रेड कर दीजिए। कभी-कभी होस्टिंग सचमुच कम पड़ जाती है। पर अक्सर ठीक वही क्रैश बड़े प्लान तक भी आपके साथ चला जाता है क्योंकि वजह आपके plugins के साथ ही शिप हो गई थी। पहले लूप को खारिज कीजिए; यह मुफ़्त है।

max_execution_time एरर ठीक करने के लिए memory_limit मत बढ़ाइए। ये अलग-अलग लिमिट हैं जिनके अलग-अलग मैसेज हैं। मेमोरी एग्ज़ॉशन कहता है “Allowed memory size … exhausted.” टाइमआउट कहता है “Maximum execution time … exceeded.” गलत वाली को बढ़ाना एक पूरी दोपहर बर्बाद करा देता है।

अब भी अटके हुए हैं?

अगर आपने पुष्टि कर ली है कि लाइव लिमिट सचमुच 256M या उससे ज़्यादा है, सारे plugins बंद करके और एक डिफ़ॉल्ट theme के साथ टेस्ट कर लिया है, और फिर भी मेमोरी एग्ज़ॉस्ट हो रही है, तो आपके पास एक असली leak है जिसे बढ़ाने लायक सीलिंग के बजाय debug log में पीछा करना चाहिए। fatal लाइन कैप्चर करें, नोट करें कि वह किस plugin की डायरेक्टरी की ओर इशारा करती है, और वही आपकी bug report है। पहले wp-config generator से अपने बेसलाइन wp-config.php कॉन्स्टेंट सही कर लें ताकि आपको पता हो कि लिमिट वहीं सेट है जहाँ आप समझ रहे हैं — फिर जाकर log पढ़ें।