Apache + Tomcat को संवाद करने में समस्याएँ होना। अस्पष्ट त्रुटि संदेश। टॉमकैट के तहत होस्ट की गई वेबसाइटों को नीचे लाना


22

सेटअप:
फेडोरा 8
अपाचे 2.2.8
टॉमकैट 5.5.8
अपाचे एजेपी का उपयोग करके अनुरोध अग्रेषित कर रहा है।

समस्या:
समय की एक निश्चित अवधि के बाद (कोई स्थिर नहीं, एक या दो घंटे के बीच हो सकता है, या एक या अधिक दिन) टॉमकैट नीचे जाएगा। या तो यह प्रतिक्रिया देना बंद कर देता है, या यह सामान्य 'सेवा अस्थायी रूप से अनुपलब्ध' को लागू करता है।

निदान:
एक ही सेटअप के साथ दो सर्वर हैं। एक उच्च ट्रैफिक वेबसाइट (प्रति सेकंड कई अनुरोध), दूसरा कम ट्रैफ़िक एक (कुछ ही मिनटों में कुछ अनुरोध)। दोनों वेबसाइट पूरी तरह से अलग कोडबेस हैं, लेकिन वे समान मुद्दों को प्रदर्शित करते हैं।

पहले सर्वर पर, जब समस्या होती है, तो सभी थ्रेड्स धीरे-धीरे उठने लगते हैं जब तक कि यह सीमा तक नहीं पहुंच जाता है (MaxThreads 200)। उस बिंदु पर सर्वर अब जवाब नहीं दे रहा है (और लंबे समय के बाद सेवा अनुपलब्ध पेज के साथ आता है)।

दूसरे सर्वर पर, जब समस्या होती है, तो अनुरोधों में लंबा समय लगता है और जब वे पूरे हो जाते हैं, तो आप सेवा अनुपलब्ध पेज है।

मैक्सट्रेड्स समस्या के उल्लेख के अलावा, टॉमकैट लॉग किसी भी विशिष्ट मुद्दों को इंगित नहीं करता है जो इसका कारण हो सकता है।

हालांकि, अपाचे लॉग में हम AJP के संदर्भ में यादृच्छिक संदेश देख रहे हैं। यहाँ यादृच्छिक संदेश का एक नमूना है जो हम देखते हैं (कोई विशिष्ट क्रम में नहीं):

[error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header
[error] (104)Connection reset by peer: ajp_ilink_receive() can't receive header
[error] proxy: AJP: disabled connection for (localhost)
[error] ajp_read_header: ajp_ilink_receive failed
[error] (120006)APR does not understand this error code: proxy: read response failed from 127.0.0.1:8009 (localhost)
[error] ap_proxy_connect_backend disabling worker for (localhost)

उच्च ट्रैफ़िक सर्वर पर हमने जो दूसरी अजीब चीज़ देखी है, वह यह है कि समस्या शुरू होने से ठीक पहले, डेटाबेस प्रश्न पहले की तुलना में अधिक समय ले रहे हैं (2000-5000 एमएस बनाम सामान्य रूप से 5-50ms)। यह केवल MaxThreads संदेश आने से पहले 2-4 सेकंड तक रहता है। मैं यह मान रहा हूँ कि सर्वर अचानक बहुत अधिक डेटा / ट्रैफ़िक / थ्रेड से निपटने का परिणाम है।

पृष्ठभूमि की जानकारी:
ये दोनों सर्वर काफी समय से बिना किसी समस्या के चल रहे थे। सिस्टम वास्तव में उस दौरान दो एनआईसी का उपयोग करके सेटअप कर रहे थे। उन्होंने आंतरिक और बाहरी यातायात को अलग कर दिया। नेटवर्क अपग्रेड के बाद, हमने इन सर्वरों को एकल एनआईसीएस में स्थानांतरित कर दिया (यह हमें सुरक्षा / सरलता कारणों के लिए अनुशंसित किया गया था)। उस परिवर्तन के बाद, सर्वरों को ये समस्याएँ होने लगीं।

रिज़ॉल्यूशन:
स्पष्ट समाधान दो एनआईसी के सेटअप में वापस जाना होगा। इसके साथ समस्याएं यह हैं कि यह नेटवर्क सेटअप के साथ कुछ जटिलताओं का कारण होगा, और ऐसा लगता है कि समस्या को अनदेखा कर रहा है। हम इसे एक एनआईसी सेटअप पर चलाने की कोशिश करना चाहते हैं।

विभिन्न त्रुटि संदेशों को देखने से कुछ भी उपयोगी नहीं मिला (या तो पुराने समाधान या हमारी समस्या से संबंधित नहीं)।

हमने विभिन्न टाइमआउट को समायोजित करने की कोशिश की है, लेकिन बस मरने से पहले सर्वर को थोड़ा लंबा चला दिया।

हमें यकीन नहीं है कि समस्या का निदान करने के लिए कहाँ देखना है। हम अभी भी तिनके पर लोभी कर रहे हैं कि समस्या क्या हो सकती है:

1) AJP और टॉमकैट के साथ सेटअप गलत है, या पुराना (यानी ज्ञात बग?)
2) नेटवर्क सेटअप (दो एनआईसी बनाम एक एनआईसी) भ्रम या थ्रूपुट समस्याएं पैदा कर रहा है।
3) वेबसाइटें स्वयं (कोई सामान्य कोड नहीं है, कोई प्लेटफ़ॉर्म इस्तेमाल नहीं किया जा रहा है, बस सर्वलेट्स और JSP के साथ मूल जावा कोड)

अद्यतन 1:
डेविड पशले की सहायक सलाह के बाद, मैंने इस मुद्दे के दौरान एक स्टैक ट्रेस / थ्रेड डंप किया। मैंने पाया कि सभी 200 धागे निम्नलिखित राज्यों में से एक में थे:

"TP-Processor200" daemon prio=1 tid=0x73a4dbf0 nid=0x70dd waiting for monitor entry [0x6d3ef000..0x6d3efeb0]
at  oracle.jdbc.pool.OracleConnectionCacheImpl.getActiveSize(OracleConnectionCacheImpl.java:988)
- waiting to lock <0x7e3455a0> (a oracle.jdbc.pool.OracleConnectionCacheImpl)
[further stack trace removed for brevity]

"TP-Processor3" daemon prio=1 tid=0x08f142a8 nid=0x652a waiting for monitor entry [0x75c7d000..0x75c7ddb0]
at oracle.jdbc.pool.OracleConnectionCacheImpl.getConnection(OracleConnectionCacheImpl.java:268)
- waiting to lock <0x7e3455a0> (a oracle.jdbc.pool.OracleConnectionCacheImpl)
[further stack trace removed for brevity]

उत्सुकता से, सभी 200 धागों में से केवल एक धागा इस अवस्था में था:

"TP-Processor2" daemon prio=1 tid=0x08f135a8 nid=0x6529 runnable [0x75cfe000..0x75cfef30]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at oracle.net.ns.Packet.receive(Unknown Source)
at oracle.net.ns.DataPacket.receive(Unknown Source)
at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
[further stack trace removed for brevity]

हो सकता है कि इस थ्रेड में ओरेकल ड्राइवर अन्य सभी थ्रेड्स को पूरा होने के लिए इंतजार करने के लिए मजबूर कर रहा हो। किसी कारण से इसे इस रीडिंग स्टेट में अटक जाना चाहिए (सर्वर कभी भी अपने आप ठीक नहीं होता है, इसके लिए पुनः आरंभ की आवश्यकता होती है)।

इससे पता चलता है कि यह या तो सर्वर और डेटाबेस के बीच नेटवर्क से संबंधित होना चाहिए, या स्वयं डेटाबेस से। हम निदान के प्रयास जारी रख रहे हैं, लेकिन कोई भी सुझाव मददगार होगा।


सबसे पहले, यह एक अजीब लिखित प्रश्न है। विवरण पर शानदार काम! दूसरा, क्या आप Apache और Tomcat सर्वर को जोड़ने के लिए प्रॉक्सी_जप या mod_jk का उपयोग कर रहे हैं?
ओफिडियन

मैं दो को जोड़ने के लिए proxy_ajp का उपयोग कर रहा हूं।
जॉर्डन बूम

घेराबंदी, joedog.org/siege-home का उपयोग करके तनाव परीक्षण करें ।
paalfe

जवाबों:


9

यह पता चला है कि ओरेकल चालक के इस संस्करण (कक्षाएं 12 - काफी पुराना) में विभिन्न बग थे जो एक गतिरोध का कारण बनते थे (जैसा कि ऊपर उद्धृत टीपी-प्रोसेसर 2 राज्य में देखा गया है)। यह तब तक सक्रिय नहीं हुआ जब तक हम नए वातावरण में नहीं गए। नवीनतम संस्करण (ojdbc14) में अपग्रेड करने से प्राथमिक सर्वर पर समस्या हल हो गई है।


यह मुझे मेरे सही समाधान की ओर ले जाता है: मेरे पास एक डीबी-पंक्ति में एक ताला था ... और कभी भी ऐप-सर्वर में कोई अपवाद नहीं मिला
cljk

6

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

  • स्टैक ट्रेस प्राप्त करें, या तो jstack का उपयोग करें या किल -3 $ process_id का उपयोग करें। मरते समय देखें कि आपके धागे क्या कर रहे हैं। यदि वे सभी डेटाबेस पर प्रतीक्षा कर रहे हैं, तो यह मेरे सिद्धांत का एक अच्छा संकेत है। हो सकता है कि वे सभी किसी ताला पर इंतजार कर रहे हों।
  • LambdaProbe स्थापित करें। यह पता लगाने के लिए अमूल्य है कि आपका टॉमकट क्या कर रहा है।
  • अपने टॉमकैट को अपग्रेड करें। 5.5.8 अविश्वसनीय रूप से पुराना है। मुझे लगता है कि अब वे 5.5.27 पर हैं।

डेविड, मैंने आपके थ्रेड डंप / स्टैक ट्रेस सुझाव के आधार पर नए निष्कर्षों के साथ सवाल (अपडेट 1 देखें) अपडेट किया है।
जॉर्डन बूम

मेरा सुझाव है कि आपका डेटाबेस कनेक्शन पूल आपके टॉमकैट अधिकतम कनेक्शन मूल्य की तुलना में बहुत छोटा है। ऐसा लगता है कि अधिकांश थ्रेड्स डेटाबेस कनेक्शन प्राप्त करने की प्रतीक्षा कर रहे हैं।
डेविड पशले

एकमात्र कारण यह है कि कई धागे हैं, क्योंकि आमतौर पर उपयोग किए जा रहे थ्रेड्स को उस थ्रेड के इंतजार में छोड़ दिया जाता है जो सॉकेट से पढ़ने का प्रयास करता है। किसी भी समय उपयोग किए जा रहे DB कनेक्शन की संख्या 1 और 3 के बीच जाती है। कभी भी इससे अधिक की आवश्यकता नहीं होती है।
जॉर्डन बूम

5

/Etc/tomcat7/server.xml में मिले अपने AJP संबंधक में कनेक्शन टाइमआउट और KeepAliveTimeout जोड़ें।

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" 
           connectionTimeout="10000" keepAliveTimeout="10000" />

Https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html पर AJP कनेक्टर के बारे में जानकारी

  • कनेक्शन टाइमआउट = मिलीसेकंड की संख्या इस कनेक्टर की प्रतीक्षा करेगी, कनेक्शन स्वीकार करने के बाद, अनुरोध के लिए यूआरआई लाइन प्रस्तुत की जाएगी। AJP प्रोटोकॉल कनेक्टर्स के लिए डिफ़ॉल्ट मान -1 (यानी अनंत) है।

  • keepAliveTimeout = कनेक्शन बंद करने से पहले इस कनेक्टर की मिलीसेकंड संख्या एक और AJP अनुरोध की प्रतीक्षा करेगी। डिफ़ॉल्ट मान कनेक्शन टाइमआउट विशेषता के लिए निर्धारित मान का उपयोग करने के लिए है।

यदि कनेक्शन टाइमआउट और KeepAliveTimeout मान परिभाषित नहीं किए जाते हैं, तो AJP कनेक्शन को अनंत के लिए जीवित रखा जाएगा। कई थ्रेड्स के कारण, डिफ़ॉल्ट अधिकतम थ्रेड्स 200 हैं।

मैं साई-जांच स्थापित करने की सलाह देता हूं - एक उन्नत प्रबंधक और अपाचे टोमैट के लिए मॉनिटर, लैम्ब्डा जांच से कांटा गया। https://code.google.com/p/psi-probe/


4

AJP के काम करने के तरीके के कारण, अपाचे के बीच लगातार कनेक्शन (या तो mod_proxy_ajp या mod_jk का उपयोग करके) केवल क्लाइंट द्वारा सुरक्षित रूप से बंद किया जा सकता है । इस मामले में, क्लाइंट एपाचे कार्यकर्ता है जो खुलता है, और फिर कार्यकर्ता प्रक्रिया के लिए जीवन के लिए टॉमकैट के लिए एक कनेक्शन रखता है ।

इस व्यवहार की वजह से आपके पास कार्यकर्त्ता कार्यकर्ता थ्रेड्स से अधिक अपाचे श्रमिक नहीं हो सकते। ऐसा करने से अतिरिक्त http कार्यकर्ता टॉमकैट से कनेक्ट करने में विफल हो जाएंगे (जैसा कि कतार पूर्ण है) और आपके बैक को DOWN के रूप में चिह्नित करेगा!


1
इन सभी वर्षों के बाद टिप्पणी के लिए क्षमा करें, लेकिन क्या यह सर्वेंट कंटेनर के MaxThreads की संख्या के लिए ProxyPass कॉन्फ़िगरेशन के भीतर अधिकतम-ध्वज सेट करके गारंटी नहीं दी जा सकती है?
होर्स्ट गुटमैन

2

मैंने स्थिरता के संदर्भ में mod_ajp के बजाय mod_proxy के साथ बेहतर परिणाम प्राप्त किए हैं, इसलिए उस समाधान का प्रयास करें। यह गैर-आक्रामक है - सबसे अच्छा यह समस्या को हल करेगा और सबसे खराब रूप से यह mod_ajp को नियंत्रित करेगा।

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


मैं इस धारणा के तहत था कि mod_proxy को हुक करने में आसान होने के बावजूद कुछ मापनीयता के मुद्दे हैं। ऐसा प्रतीत होता है कि अपाचे फाउंडेशन mod_jk ( wiki.apache.org/tomcat/FAQ/Connectors#Q2 ) की सिफारिश करता है
Ophidian

यह चिपचिपा साशन प्रदान नहीं करता है, सच है। लेकिन इसके अलावा मुझे इससे कोई समस्या नहीं है।
रॉबर्ट मुंटेनू

1

पहली बात जब मुझे लगता है कि मैं सुनता हूं कि एक सर्वर थोड़ी देर के लिए चलता है, अचानक धीमा हो जाता है और फिर सेवा विफल होने लगती है कि यह रैम से बाहर चल रहा है और स्वैप को जोर से मार रहा है। मैं इस पर स्पष्ट नहीं हूं कि एजेपी विफलताओं को आप टाइमआउट के परिणामस्वरूप देख सकते हैं, लेकिन यह पूरी तरह अनुचित नहीं है; हालांकि एनआईसी से जुड़ने का कोई स्पष्ट तरीका नहीं दिख रहा है। किसी भी घटना में, मैं आपको सलाह देता हूं कि इन घटनाओं के बारे में आपके स्मृति उपयोग के साथ क्या हो रहा है।

यदि आप रैम से बाहर चल रहे हैं, तो आपको अपनी अपाचे को बंद करने MaxClientsऔर अपनी वृद्धि करने की आवश्यकता हो सकती है ListenBacklog

वैसे, आपके प्रश्न को इतना सुनियोजित और पूर्ण बनाने के लिए धन्यवाद।


जब मैं ऐसा करते हुए 'शीर्ष' का पालन करता हूं, तो मेमोरी उपयोग काफी सुसंगत रहता है। कम से कम स्पाइक्स तो नहीं हैं। उच्च CPU उपयोग का केवल एक संक्षिप्त क्षण है।
जॉर्डन बूम

1

मुझे प्रॉक्सीहैप और टॉमकैट के साथ रेडहैट वातावरण में समान लॉग त्रुटियां थीं। Httpd पैकेज अपडेट करके हल किया गया:

yum update httpd

से:

  • httpd-devel-2.2.3-43.el5_5.3.x86_64
  • httpd-2.2.3-43.el5_5.3.x86_64

सेवा मेरे:

  • httpd-2.2.3-45.el5_6.3.x86_64
  • httpd-devel-2.2.3-45.el5_6.3.x86_64

फिर अपाचे को फिर से शुरू किया, इसके बाद टॉमकैट को फिर से शुरू किया।

उसने मेरे लिए इसे हल कर दिया!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.