🧒🏻 🚛 👍🏻 Docker में OOMkiller जितना आप सोचते हैं उससे कहीं अधिक कठिन है 🌶️ 🤳🏾 🤵🏻

फिर से हैलो। पाठ्यक्रम की शुरुआत की प्रत्याशा में "जावा डेवलपर" ने एक और छोटी सामग्री का अनुवाद तैयार किया।

हाल ही में, प्लम्ब्र एपीएम उपयोगकर्ताओं में से एक को कोड 137 के साथ डॉकटर-कंटेनर के आपातकालीन स्टॉप के साथ एक अजीब समस्या थी। एक नेस्टेड गुड़िया के समान कई नेस्टेड कंटेनर और आभासी मशीनों के साथ कॉन्फ़िगरेशन सरल था:

उबंटू के साथ खुद का लोहा सर्वर;
उबंटू के साथ कई डॉकटर कंटेनर अंदर;
डॉक कंटेनर के अंदर जावा वर्चुअल मशीन।

समस्या की जांच के दौरान, हमने इस विषय पर डॉकर प्रलेखन पाया । यह स्पष्ट हो गया कि इसका कारण या तो कंटेनर का मैनुअल स्टॉप था, या मेमोरी की कमी और ओम्कोकिलर (आउट-ऑफ-मेमोरी किलर) का हस्तक्षेप।

हम syslog को देखते हैं और देखते हैं कि, वास्तव में, ओकोकिलर कहा जाता था :

[138805.608851] java invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
[138805.608887] [<ffffffff8116d20e>] oom_kill_process+0x24e/0x3b0
[138805.608916] Task in /docker/264b771811d88f4dbd3249a54261f224a69ebffed6c7f76c7aa3bc83b3aaaf71 killed as a result of limit of /docker/264b771811d88f4dbd3249a54261f224a69ebffed6c7f76c7aa3bc83b3aaaf71
[138805.608902] [<ffffffff8116da84>] pagefault_out_of_memory+0x14/0x90
[138805.608918] memory: usage 3140120kB, limit 3145728kB, failcnt 616038
[138805.608940] memory+swap: usage 6291456kB, limit 6291456kB, failcnt 2837
[138805.609043] Memory cgroup out of memory: Kill process 20611 (java) score 1068 or sacrifice child

जैसा कि आप देख सकते हैं, जावा प्रक्रिया 3145728 KB (यह लगभग 3 जीबी है) की सीमा तक पहुंच गई, जिससे कंटेनर बंद हो गया। यह बल्कि अजीब है, क्योंकि docker खुद को 4 GB (फ़ाइल में docker-compose) की सीमा के साथ लॉन्च किया गया था ।

आप शायद जानते हैं कि जेवीएम मेमोरी उपयोग पर अपनी सीमाएं भी लगाता है। हालाँकि docker में 4 GB की सीमा निर्धारित थी, JVM को विकल्प के साथ लॉन्च किया गया था Xmx=3GB। यह और भी अधिक भ्रामक हो सकता है, लेकिन ध्यान रखें कि जेवीएम जो -Xmx इंगित करता है उससे अधिक मेमोरी का उपयोग कर सकता है ( जेवीएम में मेमोरी उपयोग का विश्लेषण करने पर लेख देखें )।

जब तक हम समझते हैं कि क्या हो रहा है। डॉकर को 4 जीबी के उपयोग की अनुमति देनी चाहिए। तो OOMkiller ने 3 GB पर काम क्यों किया? जानकारी के लिए एक और खोज ने हमें इस तथ्य तक पहुंचाया कि ओएस में मेमोरी की एक और सीमा है, जिसे हार्डवेयर पर तैनात किया गया था।

Cgroups (नियंत्रण समूहों) को धन्यवाद कहें। cgroups प्रक्रिया समूहों द्वारा संसाधन उपयोग के लिए प्रतिबंधित, नियंत्रित और लेखा के लिए एक लिनक्स कर्नेल इंजन है। अन्य समाधानों (टीम niceया /etc/security/limits.conf) की तुलना में , cgroups अधिक लचीलेपन की पेशकश करते हैं, क्योंकि वे प्रक्रियाओं के सेट के साथ काम कर सकते हैं।

हमारी स्थिति में, cgroups सीमित मेमोरी उपयोग को 3 GB (के माध्यम से memory.limit_in_bytes) करता है। हमारी कुछ प्रगति है!

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

JVM के अंदर चल रहे Java कोड बहुत सारी मेमोरी पाने की कोशिश कर रहा है।
जेवीएम ने सत्यापित किया कि 3 जीबी की एक्सएमएक्स सीमा अभी भी दूर है, ऑपरेटिंग सिस्टम के लिए मेमोरी आवंटित करने के लिए कहता है।
Docker यह भी जाँचता है और देखता है कि इसकी 4 GB सीमा भी नहीं पहुँची है।
ओएस कर्नेल 3 जीबी की cgroup सीमा की जाँच करता है और कंटेनर को मारता है।
जेवीएम कंटेनर के साथ बंद हो जाता है इससे पहले कि वह अपनी प्रक्रिया कर सके OutOfMemoryError।

इसे समझते हुए, हमने डॉकटर के लिए 2.5 जीबी और जावा के लिए 1.5 की सभी सीमाओं को कॉन्फ़िगर किया है। उसके बाद, JVM OutOfMemoryErrorएक OutOfMemoryError अपवाद को संभाल और फेंक सकता है। इसने प्लमब्र को अपना जादू करने की अनुमति दी - स्टैक के संबंधित डंप के साथ एक मेमोरी स्नैपशॉट प्राप्त करने और यह दिखाने के लिए कि डेटाबेस में एक क्वेरी थी, जिसने एक निश्चित स्थिति में लगभग पूरे डेटाबेस को लोड करने की कोशिश की।

जाँच - परिणाम

ऐसी सरल स्थिति में भी, तीन मेमोरी सीमाएँ थीं:

जेवीएम पैरामीटर के माध्यम से -Xmx
फ़ाइल में विकल्पों के माध्यम से डॉकर docker-compose
पैरामीटर के माध्यम से ऑपरेटिंग सिस्टम memory.limit_in_bytes cgroups

इस प्रकार, जब आप एक OOM हत्यारे से मुठभेड़ करते हैं, तो आपको शामिल सभी मेमोरी सीमाओं पर ध्यान देना चाहिए।

डॉक डेवलपर्स के लिए एक और निष्कर्ष। ऐसा लगता है कि इस तरह की "नेस्टेड गुड़िया" को चलाने के लिए कोई मतलब नहीं है, जिसमें संलग्न कंटेनर की मेमोरी सीमा cgroups सीमा से अधिक है। उचित चेतावनी के साथ कंटेनर को शुरू करते समय इसकी एक सरल जांच आपके उपयोगकर्ताओं के लिए सैकड़ों घंटों की डिबगिंग को बचा सकती है।

बस इतना ही। हम पाठ्यक्रम पर आपका इंतजार कर रहे हैं ।

Docker में OOMkiller जितना आप सोचते हैं उससे कहीं अधिक कठिन है

जाँच - परिणाम

More articles: