सवाल एडब्ल्यूएस ईएलबी अपाचे 2 503 सेवा अनुपलब्ध: बैक-एंड सर्वर क्षमता पर है


हम लगभग दो साल से अमेज़ॅन एडब्लूएस इंफ्रास्ट्रक्चर से कुछ वेबसाइटें चला रहे हैं और लगभग दो दिन पहले वेबसर्वर दिन में एक या दो बार नीचे जाने लगा, केवल एक ही त्रुटि के साथ मैं यह पाया जा सकता हूं:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

क्लाउडवॉच द्वारा कोई अलार्म (सीपीयू / डिस्क आईओ / डीबी कॉन) ट्रिगर नहीं किया जा रहा है। मैंने ईएलबी को छोड़ने के लिए लोचदार आईपी के माध्यम से साइट पर जाने की कोशिश की और इसे प्राप्त किया:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

मैं अपाचे लॉग में सामान्य से कुछ भी नहीं देखता और सत्यापित करता हूं कि उन्हें ठीक से घुमाया जा रहा था। एसएसएच के माध्यम से "डाउन" होने पर मुझे मशीन तक पहुंचने में कोई समस्या नहीं है और प्रक्रिया सूची को देखते हुए मुझे 151 अपाचे 2 प्रक्रियाएं दिखाई देती हैं जो मेरे लिए सामान्य दिखाई देती हैं। अपाचे को पुनरारंभ करना अस्थायी रूप से समस्या को हल करता है। यह मशीन ईएलबी के पीछे सिर्फ एक वेबसर्वर के रूप में काम करती है। किसी भी सुझाव के लिए बहुत आभार होगा।

सीपीयू का उपयोग       औसत: 7.45%, न्यूनतम: 0.00%, अधिकतम: 25.82%

मेमोरी उपयोग       औसत: 11.04%, न्यूनतम: 8.76%, अधिकतम: 13.84%

स्वैप उपयोग करें       औसत: एन / ए, न्यूनतम: एन / ए, अधिकतम: एन / ए

डिस्क स्थान उपयोग / dev / xvda1 पर आरोहित /       औसत: 62.18%, न्यूनतम: 53.3 9%, अधिकतम: 65.4 9%

मुझे स्पष्टीकरण दें कि मुझे लगता है कि यह मुद्दा व्यक्तिगत ईसी 2 उदाहरण के साथ है और ईएलबी नहीं, मैं सिर्फ उस पर शासन नहीं करना चाहता था, भले ही मैं लोचदार आईपी तक पहुंचने में असमर्थ था। मुझे संदेह है कि ईएलबी वास्तविक ईसी 2 उदाहरण को मारने के नतीजों को वापस कर रहा है।

अद्यतन: 2014-08-26 मुझे इसे जल्द से जल्द अपडेट करना चाहिए था लेकिन "फिक्स" "खराब" उदाहरण का स्नैपशॉट लेना था और परिणामी एएमआई शुरू करना था। तब से यह नीचे नहीं चला है। मैंने स्वास्थ्य जांच को देखा जब मुझे अभी भी समस्याएं आ रही थीं और स्वास्थ्य जांच पृष्ठ पर जा सकती थीं (curl http://localhost/page.html) यहां तक ​​कि जब मुझे लोड बैलेंसर से क्षमता के मुद्दे मिल रहे थे। मुझे विश्वास नहीं है कि यह एक स्वास्थ्य जांच मुद्दा था, लेकिन चूंकि अमेज़ॅन समेत कोई भी बेहतर जवाब नहीं दे सकता है, मैं इसे उत्तर के रूप में चिह्नित कर रहा हूं। धन्यवाद।

अद्यतन: 2015-05-06 मैंने सोचा कि मैं यहां वापस आऊंगा और कहूंगा कि इस मुद्दे का हिस्सा अब मैं दृढ़ता से विश्वास करता हूं कि स्वास्थ्य जांच सेटिंग थी। मैं एएमआई के साथ किसी मुद्दे के बारे में इनकार नहीं करना चाहता क्योंकि एएमआई लॉन्च होने के बाद यह निश्चित रूप से बेहतर हो गया था, लेकिन मुझे पता चला कि प्रत्येक लोड बैलेंसर के लिए हमारी स्वास्थ्य जांच अलग थी और जिसकी सबसे अधिक परेशानी थी वास्तव में आक्रामक अस्वास्थ्यकर दहलीज और प्रतिक्रिया समय समाप्ति थी। हमारा यातायात अप्रत्याशित रूप से बढ़ता रहता है और मुझे लगता है कि आक्रामक स्वास्थ्य जांच सेटिंग्स और यातायात में स्पाइक्स के बीच यह एक सही तूफान था। इस मुद्दे का निदान करने में मुझे इस तथ्य पर ध्यान केंद्रित किया गया कि मैं फिलहाल स्वास्थ्य जांच अंतराल तक पहुंच सकता हूं लेकिन यह संभव है कि विलंबता के कारण स्वास्थ्य जांच विफल हो गई और फिर हमारे पास उच्च स्वस्थ दहलीज थी (उस विशेष ईएलबी के लिए) तो यह होगा फिर से स्वस्थ होने के रूप में उदाहरण देखने के लिए ले लो।


36
2017-11-21 21:03


मूल


मुझे इसके बारे में अधिक जानकारी मिली: meta.discourse.org/t/... - Andre Mesquita


जवाब:


ईएलबी लोड बैलेंसर अपनी स्वास्थ्य जांच करता है और गलत कॉन्फ़िगरेशन (आमतौर पर नाम वर्चुअल होस्ट के साथ) के कारण "पृष्ठ नहीं मिला" (या अन्य सरल त्रुटि) प्राप्त करता है, तो आपको "बैक-एंड सर्वर क्षमता पर" प्राप्त होगा।

"ईएलबी-हेल्थ चेकर" उपयोगकर्ता एजेंट का उपयोग कर लॉग फाइल फ़ोल्डर को grepping करने का प्रयास करें। जैसे

grep ELB-HealthChecker  /var/log/httpd/*

यह आम तौर पर आपको 4x या 5x त्रुटि देगा जो आसानी से तय किया जा सकता है। जैसे बाढ़, मैक्सक्लिंट इत्यादि समस्या को बहुत अधिक क्रेडिट दे रही है।

एफवाईआई अमेज़ॅन: अनुरोध से लौटाई गई प्रतिक्रिया क्यों न दिखाएं? यहां तक ​​कि एक स्टेटस कोड भी मदद करेगा।


37
2018-02-10 23:28





मैं बस इस मुद्दे में खुद भाग गया। यदि कोई स्वस्थ उदाहरण नहीं है तो अमेज़ॅन ईएलबी इस त्रुटि को वापस कर देगा। हमारी साइट्स को गलत कॉन्फ़िगर किया गया था, इसलिए ईएलबी हेल्थ चेक विफल रहा था, जिससे ईएलबी दो सर्वरों को रोटेशन से बाहर ले गया। शून्य स्वस्थ साइटों के साथ, ईएलबी ने 503 सेवा अनुपलब्ध कर दी: बैक-एंड सर्वर क्षमता पर है।


17
2017-08-14 16:02





[प्रश्न को बेहतर समझने के बाद संपादित करें] ईएलबी का कोई अनुभव नहीं है, मुझे अभी भी लगता है कि यह संदिग्ध रूप से 503 त्रुटि की तरह लगता है जिसे अपाचे को टॉमकैट मोड़ने और कनेक्शन में बाढ़ आने पर फेंक दिया जा सकता है।

प्रभाव यह है कि अगर अपाचे बैकएंड द्वारा संसाधित किए जाने से अधिक कनेक्शन अनुरोध प्रदान करता है, तो बैकएंड इनपुट कतार भर जाती है जब तक कि कोई और कनेक्शन स्वीकार नहीं किया जा सके। जब ऐसा होता है, तो अपाचे की संबंधित आउटपुट कतार भरना शुरू हो जाती है। जब कतार पूर्ण होती है तो अपाचे 503 फेंकता है। यह तब भी होगा जब अपाचे बैकएंड होता है, और फ्रंटेंड इस तरह की दर पर पहुंचाता है कि कतार भरने के लिए।

(काल्पनिक) समाधान बैकएंड के इनपुट कनेक्टर और फ्रंटेंड के आउटपुट कनेक्टर का आकार है। यह अनुमानित बाढ़ स्तर और शामिल कंप्यूटरों की उपलब्ध रैम के बीच संतुलित संतुलन में बदल जाता है।

तो ऐसा होने पर, अपनी अधिकतम सेटिंग्स की जांच करें और अपाचे (mod_status।) में अपने व्यस्त श्रमिकों की निगरानी करें। यदि संभव हो तो वही करें जो ईएलबी है जो टॉमकैट्स कनेक्टर बैकलॉग, मैक्सथ्रेड इत्यादि से मेल खाता है। संक्षेप में, अपाचे की इनपुट कतारों और ईएलबी की आउटपुट कतारों से संबंधित सबकुछ देखें।

हालांकि मैं पूरी तरह से समझता हूं कि यह सीधे लागू नहीं है, इस लिंक में अपाचे कनेक्टर के लिए एक आकार देने वाली मार्गदर्शिका है। आपको संबंधित ईएलबी कतार तकनीकीताओं की खोज करने की आवश्यकता होगी, फिर गणित करें: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc/

जैसा कि नीचे टिप्पणी में देखा गया है, अपाचे कनेक्टर को जबरदस्त करने के लिए यातायात में एक स्पाइक एकमात्र संभावना नहीं है। यदि कुछ अनुरोध दूसरों की तुलना में धीमे सेवा में हैं, तो उनमें से एक उच्च अनुपात भी कनेक्टर कतार भरने के लिए नेतृत्व कर सकते हैं। यह मेरे मामले में सच था।

साथ ही, जब यह मेरे साथ हुआ तो मुझे परेशान था कि मुझे 503: फिर से सेवा न करने के लिए अपाचे सेवा को पुनरारंभ करना पड़ा। बस कनेक्टर बाढ़ का इंतजार पर्याप्त नहीं था। मुझे यह पता नहीं चला कि, क्या कोई अपाचे में अपने कैश से सेवा कर सकता है?

श्रमिकों की संख्या और संबंधित प्री-फोर्क मैक्सक्लिएंट सेटिंग्स को बढ़ाने के बाद (यह विंडोज़ पर मल्टीथ्रेडेड अपाचे था जिसमें कतारों के लिए कुछ अन्य निर्देश हैं यदि मुझे सही याद है), 503-समस्या गायब हो गई। मैंने वास्तव में गणित नहीं किया, लेकिन जब तक मैं कतार संसाधनों की चोटी की खपत के लिए विस्तृत मार्जिन नहीं देख पाता, तब तक मूल्यों को tweaked। मैंने इसे उस पर जाने दिया।

उम्मीद है कि यह कुछ मदद की थी।


5
2017-11-21 21:29



मुझे बस एहसास हुआ कि आप अपाचे लिख रहे हैं आपका बैकएंड है। फिर भी, श्रमिक, maxclients इत्यादि मुझे लगता है कि, हालांकि मेरा जवाब बहुत दूर है और एक पूर्ण पुनर्लेख की जरूरत है। मैं इसे इसके बजाय हटा सकता हूं। सबक सीखा: सवाल ठीक से पढ़ें। - ErikE
धन्यवाद। इस मामले के लिए यातायात में एक बड़ा स्पाइक होना होगा? और एक बार कहा कि यातायात छोड़ने अपाचे को ठीक करने में सक्षम नहीं होना चाहिए? - JSP
सिद्धांत रूप में, हाँ। हालांकि, जब यह मेरे साथ हुआ है तो मुझे सेवा को पुनरारंभ करना पड़ा। इसने मुझे उन स्थानों पर पहली बार देखा जहां वास्तव में जो हुआ उससे कोई लेना देना नहीं था, लेकिन उचित निदान और इलाज के बाद भी मैं सेवा पुनरारंभ की आवश्यकता को समझने में सक्षम नहीं हूं। मुझे चुपचाप संदेह था कि यह विंडोज पर अपाचे चलाने के कारण था, क्योंकि मुझे एक असंबंधित बग संदर्भ मिला जो स्पष्ट रूप से उस कॉम्बो के साथ सामने आया था। किसी भी मामले में बहुत अजीब। - ErikE
और हां, कनेक्टर्स को जबरदस्त यातायात था - स्पाइकी नहीं (हमारे लिए) लेकिन बहुत अधिक। यह कुछ निश्चित अनुरोध थे जो सेवा के लिए धीमे थे जो अवसर पर बहुत से लोग आए थे। थोड़ा सा निगरानी करने के बाद और संबंधित मूल्यों को ऊपर उठाने के बाद 503 के बाद के पुनरारंभ के लिए आवश्यकता के साथ गायब हो गया। - ErikE


आप एल्ब हेल्थ चेकर के मूल्यों को बढ़ा सकते हैं, इसलिए एक धीमी प्रतिक्रिया एक सर्वर को एल्ब से खींच नहीं लेती है। बेहतर है कि कुछ उपयोगकर्ताओं को सेवा के लिए अनुपलब्ध हो, साइट की तुलना में सभी के लिए नीचे जा रहा है।

संपादित करें: हम स्वास्थ्य जांच टाइमआउट को 25 सेकंड तक बढ़ाकर प्री-वार्मिंग कैश के बिना दूर हो सकते हैं ...... 1-2 मिनट के बाद ... साइट नरक के रूप में उत्तरदायी है

EDIT :: केवल मांग पर एक गुच्छा लॉन्च करें, और जब आपका निगरानी उपकरण प्रबंधन दिखाता है कि आप कितने तेज़ हैं, तो बस प्रीआई आरआई अमेज़ॅन: पी

संपादित करें: यह संभव है, एक बैकएंड एएलबी पंजीकृत उदाहरण पर्याप्त नहीं है। बस कुछ और लॉन्च करें, और उन्हें एल्ब के साथ पंजीकृत करें, और इससे आपको अपनी समस्या को कम करने में मदद मिलेगी


4
2017-11-21 21:57





यह कुछ साल देर हो चुकी है, लेकिन उम्मीद है कि यह किसी की मदद करता है।

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


0
2017-08-05 02:36