सेटअप:
फेडोरा 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]
हो सकता है कि इस थ्रेड में ओरेकल ड्राइवर अन्य सभी थ्रेड्स को पूरा होने के लिए इंतजार करने के लिए मजबूर कर रहा हो। किसी कारण से इसे इस रीडिंग स्टेट में अटक जाना चाहिए (सर्वर कभी भी अपने आप ठीक नहीं होता है, इसके लिए पुनः आरंभ की आवश्यकता होती है)।
इससे पता चलता है कि यह या तो सर्वर और डेटाबेस के बीच नेटवर्क से संबंधित होना चाहिए, या स्वयं डेटाबेस से। हम निदान के प्रयास जारी रख रहे हैं, लेकिन कोई भी सुझाव मददगार होगा।