🖐🏿 🕺🏾 🔘 हमने अपने आप को पैर में कैसे गोली मार ली और यह पता लगाने की कोशिश की कि वास्तव में क्या है 📨 🥥 🥤

कॉर्पोरेट ब्लॉग पर पिछली पोस्ट में एक भी कंसोल टीम नहीं थी, और हमने पकड़ने का फैसला किया।

हमारी कंपनी के पास साझा होस्टिंग पर बड़े फेकैप्स को रोकने के लिए एक मीट्रिक है। प्रत्येक साझा होस्टिंग सर्वर पर वर्डप्रेस पर एक परीक्षण साइट है, जो समय-समय पर एक्सेस की जाती है।

यह है कि परीक्षण साइट प्रत्येक साझा होस्टिंग सर्वर पर कैसे दिखता है

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

हमने इस अपटाइम मेट्रिक को (परीक्षण स्थल से सभी अनुरोधों के परीक्षण के लिए सफल प्रतिक्रियाओं का प्रतिशत) कहा है। बहुत अच्छा नाम नहीं है, इसे अपटाइम-कौन-कुल-कुल-समय-अंतिम-रिबूट-सर्वर के साथ भ्रमित करना आसान है।

गर्मियां बीत गईं और अपटाइम शेड्यूल धीरे-धीरे नीचे चला गया।

व्यवस्थापकों ने तुरंत कारण की पहचान की - रैम की कमी। लॉग में OOM मामलों को देखना आसान था जब सर्वर मेमोरी से बाहर चला गया और कर्नेल ने नग्नेक्स को मार दिया।

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

एक-एक करके, प्रशासक परिणामों के साथ लौटते हैं। प्रत्येक उसे आवंटित क्षेत्र में स्मृति की खपत को कम करने में कामयाब रहा। उदाहरण के लिए, nginx के मामले में, एक शामिल लेकिन इस्तेमाल नहीं किया mod_security का पता लगाया गया था। इस बीच, OOM भी अक्सर होता है।

अंत में, यह नोटिस करना संभव है कि कोर मेमोरी की खपत (विशेष रूप से, सुएनरेक्लेम) कुछ सर्वरों पर बहुत बड़ी है। न तो ps आउटपुट में और न ही htop में यह पैरामीटर दिखाई देता है, इसलिए हमने इसे तुरंत नोटिस नहीं किया! उदाहरण के लिए सर्वर

root@vh28.timeweb.ru:~# grep SU /proc/meminfo SUnreclaim: 25842956 kB

24 गीगाबाइट रैम को कर्नेल को दिया जाता है, और कर्नेल उन्हें खर्च करता है, किसी को पता नहीं है कि क्या है!

व्यवस्थापक (चलो उसे गेब्रियल कहते हैं) लड़ाई में भाग जाता है। रिसाव का पता लगाने के लिए KMEMLEAK विकल्पों के साथ कर्नेल को दोबारा बनाता है।

पुनर्निर्माण के लिए विकल्प

KMEMLEAK को सक्षम करने के लिए, बस नीचे सूचीबद्ध विकल्पों को निर्दिष्ट करें और कर्नेल को kmemleak = पैरामीटर पर लोड करें।

 CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=10000

KMEMLEAK इन पंक्तियों को ( /sys/kernel/debug/kmemleak ) /sys/kernel/debug/kmemleak :

 unreferenced object 0xffff88013a028228 (size 8): comm "apache2", pid 23254, jiffies 4346187846 (age 1436.284s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50 [<ffffffff811d450a>] kmem_cache_alloc_trace+0xca/0x1d0 [<ffffffff8136dcc3>] apparmor_file_alloc_security+0x23/0x40 [<ffffffff81332d63>] security_file_alloc+0x33/0x50 [<ffffffff811f8013>] get_empty_filp+0x93/0x1c0 [<ffffffff811f815b>] alloc_file+0x1b/0xa0 [<ffffffff81728361>] sock_alloc_file+0x91/0x120 [<ffffffff8172b52e>] SyS_socket+0x7e/0xc0 [<ffffffff81003854>] do_syscall_64+0x54/0xc0 [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff880d67030280 (size 624): comm "hrrb", pid 23713, jiffies 4346190262 (age 1426.620s) hex dump (first 32 bytes): 01 00 00 00 03 00 ff ff 00 00 00 00 00 00 00 00 ................ 00 e7 1a 06 10 88 ff ff 00 81 76 6e 00 88 ff ff ..........vn.... backtrace: [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50 [<ffffffff811d4337>] kmem_cache_alloc+0xc7/0x1d0 [<ffffffff8172a25d>] sock_alloc_inode+0x1d/0xc0 [<ffffffff8121082d>] alloc_inode+0x1d/0x90 [<ffffffff81212b01>] new_inode_pseudo+0x11/0x60 [<ffffffff8172952a>] sock_alloc+0x1a/0x80 [<ffffffff81729aef>] __sock_create+0x7f/0x220 [<ffffffff8172b502>] SyS_socket+0x52/0xc0 [<ffffffff81003854>] do_syscall_64+0x54/0xc0 [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a [<ffffffffffffffff>] 0xffffffffffffffff

गेब्रियल ने अपने सभी रहस्यों को हमारे सामने प्रकट नहीं किया और यह नहीं बताया कि कैसे उन्होंने उपरोक्त पंक्तियों से स्मृति रिसाव के सटीक कारण का पता लगाया। सबसे अधिक संभावना है, उन्होंने सटीक लाइन खोजने के लिए addr2line /usr/lib/debug/lib/modules/`uname -r`/vmlinux ffffffff81722361 का उपयोग किया। या सिर्फ net/socket.c खोला और उस पर तब तक गौर किया जब तक कि फाइल असहज नहीं हो गई।

यह समस्या net/socket.c पर एक पैच बन गई, जिसे कई साल पहले हमारी रिपॉजिटरी में जोड़ा गया था। इसका उद्देश्य ग्राहकों को बाइंड () सिस्टम कॉल का उपयोग करने से रोकना है, यह क्लाइंट द्वारा शुरू किए जाने वाले प्रॉक्सी सर्वर के खिलाफ एक सरल सुरक्षा है। पैच ने अपने उद्देश्य को पूरा किया, लेकिन स्मृति को खुद के बाद साफ नहीं किया।
शायद PHP में नए फैशनेबल मैलवेयर थे जो एक लूप में प्रॉक्सी सर्वर को चलाने की कोशिश करते थे - जिसके कारण सैकड़ों हजारों अवरुद्ध बाइंड () कॉल और खो गए गीगाबाइट रैम।

तब यह सरल था - गेब्रियल ने पैच को ठीक किया और कर्नेल को फिर से बनाया। लिनक्स चलाने वाले सभी सर्वरों पर SUnreclaim के मूल्य की निगरानी। इंजीनियरों ने ग्राहकों को चेतावनी दी और नए कोर में होस्टिंग को फिर से शुरू किया।
ओओएम गायब हो गया।

लेकिन साइटों की उपलब्धता की समस्या बनी रही

सभी सर्वरों पर, परीक्षण साइट ने दिन में कई बार प्रतिक्रिया करना बंद कर दिया।

यहां, लेखक शरीर के विभिन्न हिस्सों पर बाल फाड़ना शुरू कर देगा। लेकिन गेब्रियल शांत रहे और उन्होंने होस्टिंग सर्वर के कुछ हिस्सों को यातायात की रिकॉर्डिंग में बदल दिया।

ट्रैफिक डंप में, यह देखा गया था कि TCP RST पैकेट की अचानक प्राप्ति के बाद अक्सर परीक्षण साइट के लिए अनुरोध गिर जाता है। दूसरे शब्दों में, अनुरोध सर्वर पर पहुंच गया, लेकिन कनेक्शन समाप्त हो गया नगनेक्स द्वारा टूट गया।
और भी दिलचस्प! गेब्रियल द्वारा शुरू की गई स्ट्रेस यूटिलिटी से पता चलता है कि नगनेक्स डेमन इस पैकेट को नहीं भेज रहा है। यह कैसे हो सकता है, क्योंकि पोर्ट 80 पर केवल नगनेक्स ही सुन रहा है?
कारण कई कारकों का एक संयोजन था:

nginx सेटिंग्स में, reuseport विकल्प reuseport ( SO_REUSEPORT सॉकेट SO_REUSEPORT सहित), जो विभिन्न प्रक्रियाओं को एक ही पते और पोर्ट पर कनेक्शन स्वीकार करने की अनुमति देता है
nginx 1.13.0 का नवीनतम (उस समय) संस्करण, बग है जिसके कारण nginx -t माध्यम से nginx -t कॉन्फ़िगरेशन परीक्षण शुरू करने और SO_REUSEPORT का उपयोग करते हुए SO_REUSEPORT यह nginx परीक्षण प्रक्रिया वास्तव में पोर्ट 80 को सुनने और वास्तविक ग्राहकों से अनुरोधों को सुनने के लिए है। । और कॉन्फ़िगरेशन परीक्षण प्रक्रिया के अंत में, ग्राहकों को Connection reset by peer प्राप्त हुआ
अंत में, zabbix की निगरानी में, nginx कॉन्फ़िगरेशन शुद्धता की निगरानी को सभी सर्वरों पर nginx स्थापित के साथ कॉन्फ़िगर किया गया था: nginx -t कमांड को एक मिनट में एक बार कॉल किया गया था।

नगनेक्स को अपडेट करने के बाद ही आप शांति से सांस ले सकते हैं। साइटों का अपटाइम ग्राफ ऊपर चला गया है।

इस पूरी कहानी का नैतिक क्या है? आशावादी बनें और स्व-इकट्ठे गुठली का उपयोग करने से बचें।

हमने अपने आप को पैर में कैसे गोली मार ली और यह पता लगाने की कोशिश की कि वास्तव में क्या है

लेकिन साइटों की उपलब्धता की समस्या बनी रही

More articles: