सिस्टम प्रदर्शन पर पारदर्शी विशाल पृष्ठों का प्रभाव

लेख जॉन अकालमत्सेव , जिगा की ओर से प्रकाशित किया जाता है

Tinkoff.ru आज केवल एक बैंक नहीं है, यह एक आईटी कंपनी है। यह न केवल बैंकिंग सेवाएं प्रदान करता है, बल्कि उनके आसपास एक पारिस्थितिकी तंत्र भी बनाता है।

हम Tinkoff.ru पर ग्राहक सेवा की गुणवत्ता में सुधार करने के लिए विभिन्न सेवाओं के साथ साझेदारी करते हैं, और बेहतर सेवाएं बनने में मदद करते हैं। उदाहरण के लिए, हमने ऐसी सेवाओं में से एक का लोड परीक्षण और प्रदर्शन विश्लेषण किया, जिसने सिस्टम में अड़चनों को खोजने में मदद की - जिसमें ओएस विन्यास में पारदर्शी विशाल पृष्ठ शामिल थे।

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

समस्या का वर्णन

फिलहाल, सेवा वास्तुकला है:

• Http कनेक्शनों को संभालने के लिए Nginx वेब सर्वर
• Php-fpm php प्रक्रिया नियंत्रण के लिए
• कैशिंग के लिए रेडिस
• डेटा भंडारण के लिए PostgreSQL
• एक बंद खरीदारी समाधान

उच्च लोड के तहत अगली बिक्री के दौरान हमें जो मुख्य समस्या मिली, वह सीपीयू का उच्च उपयोग था, जबकि कर्नेल मोड (सिस्टम समय) में प्रोसेसर का समय बढ़ा और उपयोगकर्ता मोड (उपयोगकर्ता समय) में समय से अधिक था।

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

प्रणाली की प्राथमिक विशेषताओं का निर्धारण

शुरू करने के लिए, हमने उत्पादक के करीब संसाधनों के साथ एक लोड सर्किट एकत्र किया, और एक सामान्य दिन में एक सामान्य लोड के अनुरूप लोड प्रोफाइल संकलित किया।

गैटलिंग संस्करण 3 को शेलिंग टूल के रूप में चुना गया था, और शेलटिंग को स्थानीय नेटवर्क के अंदर गिटलैब-रनर के माध्यम से किया गया था। एक ही स्थानीय नेटवर्क में एजेंटों और लक्ष्यों का स्थान नेटवर्क की कम लागत के कारण होता है, इसलिए हम कोड के निष्पादन की जांच करने पर ध्यान केंद्रित करते हैं, न कि उस बुनियादी ढांचे के प्रदर्शन पर जहां सिस्टम तैनात है।

सिस्टम की प्राथमिक विशेषताओं का निर्धारण करते समय, http कॉन्फ़िगरेशन के साथ रैखिक रूप से बढ़ते लोड के साथ एक परिदृश्य उपयुक्त है:

val httpConfig: HttpProtocolBuilder = http .baseUrl("https://test.host.ru") .inferHtmlResources() //      .disableCaching //  ,      "" . .disableFollowRedirect //   /// MULTIPLIER   JAVA_OPTS setUp( Scenario.inject( rampUsers(100 * MULTIPLIER) during (200 * MULTIPLIER seconds)) ).protocols(httpConfig) .maxDuration(1 hour) 

इस स्तर पर, हमने मुख्य पृष्ठ को खोलने और सभी संसाधनों को डाउनलोड करने के लिए एक स्क्रिप्ट लागू की

इस परीक्षण के परिणामों ने 1500 आरपीएस का अधिकतम प्रदर्शन दिखाया, लोड की तीव्रता में और वृद्धि के कारण सॉफ्टरिक समय बढ़ने के साथ जुड़े सिस्टम का क्षरण हुआ।

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

मुख्य समस्या के संदेह की पुष्टि नहीं की गई थी, क्योंकि कम नेटवर्क गतिविधि के साथ ठेस पर बहुत लंबा सिस्टम समय था।

उपयोगकर्ता स्क्रिप्ट

अगला कदम कस्टम स्क्रिप्ट विकसित करना और चित्रों के साथ एक पृष्ठ खोलने से अधिक कुछ जोड़ना था। प्रोफ़ाइल में भारी ऑपरेशन शामिल हैं, जो साइट कोड और डेटाबेस को पूरी तरह से शामिल करता है, न कि एक वेब सर्वर जो स्थैतिक संसाधन देता है।

स्थिर भार के साथ परीक्षण अधिकतम से कम तीव्रता पर शुरू किया गया था, कॉन्फ़िगरेशन में एक पुनर्निर्देशित संक्रमण जोड़ा गया था:

 val httpConfig: HttpProtocolBuilder = http .baseUrl("https://test.host.ru") .inferHtmlResources() //      .disableCaching //  ,      "" . /// MULTIPLIER   JAVA_OPTS setUp( MainScenario .inject(rampUsers(50 * MULTIPLIER) during (200 * MULTIPLIER seconds)), SideScenario .inject(rampUsers(100 * MULTIPLIER) during (200 * MULTIPLIER seconds)) ).protocols(httpConfig) .maxDuration(2 hours) 

प्रणालियों के सबसे पूर्ण उपयोग ने सिस्टम समय मीट्रिक में वृद्धि के साथ-साथ स्थिरता परीक्षण के दौरान इसकी वृद्धि को दिखाया। उत्पादन पर्यावरण के साथ इस मुद्दे को पुन: पेश किया गया था।

रेडिस के साथ नेटवर्किंग

समस्याओं का विश्लेषण करते समय, यह समझने के लिए कि यह कैसे काम करता है और आपूर्ति किए गए लोड का इस पर क्या प्रभाव पड़ता है, सिस्टम के सभी घटकों की निगरानी करना बहुत महत्वपूर्ण है।

रेडिस मॉनिटरिंग के आगमन के साथ, सिस्टम के सामान्य मैट्रिक्स को नहीं, बल्कि इसके विशिष्ट घटकों को देखना संभव हो गया। तनाव परीक्षण के लिए परिदृश्य भी बदला गया था, जो अतिरिक्त निगरानी के साथ मिलकर समस्या के स्थानीयकरण से संपर्क करने में मदद करता है।

निगरानी में, रेडिस ने सीपीयू उपयोग के साथ एक समान तस्वीर देखी, या बल्कि, सिस्टम का समय उपयोगकर्ता के समय की तुलना में काफी लंबा है, जबकि सीपीयू का मुख्य उपयोग सेट ऑपरेशन में था, अर्थात मूल्य को संग्रहीत करने के लिए रैम का आवंटन।

रेडिस के साथ नेटवर्क इंटरैक्शन के प्रभाव को खत्म करने के लिए, परिकल्पना का परीक्षण करने और Redc को tcp सॉकेट के बजाय UNIX सॉकेट में बदलने का निर्णय लिया गया। यह फ्रेमवर्क में सही किया गया था जिसके माध्यम से php-fpm डेटाबेस से जुड़ता है। फ़ाइल /yiisoft/yii/framework/caching/CRedisCache.php में, हमने होस्ट को लाइन से प्रतिस्थापित किया: हार्डकोड redis.sock के साथ पोर्ट। लेख में सॉकेट प्रदर्शन के बारे में अधिक पढ़ें।

  /** * Establishes a connection to the redis server. * It does nothing if the connection has already been established. * @throws CException if connecting fails */ protected function connect() { $this->_socket=@stream_socket_client( // $this->hostname.':'.$this->port, "unix:///var/run/redis/redis.sock", $errorNumber, $errorDescription, $this->timeout ? $this->timeout : ini_get("default_socket_timeout"), $this->options ); if ($this->_socket) { if($this->password!==null) $this->executeCommand('AUTH',array($this->password)); $this->executeCommand('SELECT',array($this->database)); } else { $this->_socket = null; throw new CException('Failed to connect to redis: '.$errorDescription,(int)$errorNumber); } } 

दुर्भाग्य से, इससे बहुत प्रभाव नहीं पड़ा। CPU उपयोग थोड़ा स्थिर हुआ, लेकिन हमारी समस्या का समाधान नहीं हुआ - CPU उपयोग का अधिकांश भाग कर्नेल मोड कंप्यूटिंग में था।

बेंचमार्क तनाव का उपयोग और THP समस्याओं की पहचान

तनाव उपयोगिता ने समस्या को स्थानीय बनाने में मदद की - पॉसिक्स सिस्टम के लिए एक सरल वर्कलोड जनरेटर, जो व्यक्तिगत सिस्टम घटकों को लोड कर सकता है, उदाहरण के लिए, सीपीयू, मेमोरी, आईओ।
परीक्षण हार्डवेयर और OS संस्करण पर माना जाता है:

उबंटू 18.04.1 एलटीएस
12 इंटेल® Xeon® सीपीयू

उपयोगिता का उपयोग कमांड द्वारा किया जाता है:

 sudo apt-get install stress 

हम देखते हैं कि सीपीयू को लोड के तहत कैसे उपयोग किया जाता है, एक परीक्षण चलाएं जो 300 सेकंड की अवधि के साथ वर्गाकार जड़ों की गणना के लिए श्रमिक बनाता है:

 -c, --cpu N spawn N workers spinning on sqrt() > stress --cpu 12 --timeout 300s stress: info: [39881] dispatching hogs: 12 cpu, 0 io, 0 vm, 0 hdd 

ग्राफ उपयोगकर्ता मोड में पूर्ण उपयोग दिखाता है - इसका मतलब है कि सभी प्रोसेसर कोर लोड किए गए हैं और उपयोगी गणना की जाती है, न कि सिस्टम सेवा कॉल।

अगला कदम io के साथ गहनता से काम करते समय संसाधनों का उपयोग करना है। सिंक () निष्पादित करने वाले 12 श्रमिकों के निर्माण के साथ 300 सेकंड के लिए परीक्षण चलाएं। सिंक कमांड डिस्क से मेमोरी में बफ़र किए गए डेटा को लिखता है। कर्नेल बार-बार (आमतौर पर धीमी) डिस्क को पढ़ने और लिखने के संचालन से बचने के लिए मेमोरी में डेटा संग्रहीत करता है। सिंक () कमांड यह सुनिश्चित करता है कि मेमोरी में संग्रहीत सब कुछ डिस्क पर लिखा जाए।

 -i, --io N spawn N workers spinning on sync() > stress --io 12 --timeout 300s stress: info: [39907] dispatching hogs: 0 cpu, 0 io, 0 vm, 12 hdd 

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

यह आपकी स्मृति की जांच करने का समय है। हम 20 श्रमिकों को लॉन्च करते हैं जो कमांड का उपयोग करके 300 सेकंड के लिए आवंटित करेंगे और मुफ्त मेमोरी:

  -m, --vm N spawn N workers spinning on malloc()/free() > stress -m 20 --timeout 300s stress: info: [39954] dispatching hogs: 0 cpu, 0 io, 20 vm, 0 hdd 

तुरंत हम सिस्टम मोड में सीपीयू के उच्च उपयोग और उपयोगकर्ता मोड में थोड़ा देखते हैं, साथ ही 2 जीबी से अधिक रैम का उपयोग करते हैं।

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

अधिकांश आधुनिक ऑपरेटिंग सिस्टम में, वर्चुअल मेमोरी को पेजिंग का उपयोग करके आयोजित किया जाता है, इस दृष्टिकोण के साथ, पूरे मेमोरी क्षेत्र को एक निश्चित लंबाई के पन्नों में विभाजित किया जाता है, उदाहरण के लिए 4096 बाइट्स (कई प्लेटफार्मों के लिए डिफ़ॉल्ट), और जब आवंटित करते हैं, उदाहरण के लिए, 2 जीबी मेमोरी, मेमोरी मैनेजर को संचालित करना होगा 500,000 से अधिक पृष्ठ। इस दृष्टिकोण में, बड़े प्रबंधन ओवरहेड्स और विशाल पृष्ठ हैं और उन्हें कम करने के लिए पारदर्शी विशाल पृष्ठ तकनीकों का आविष्कार किया गया था, उनकी मदद से आप पृष्ठ का आकार बढ़ा सकते हैं, उदाहरण के लिए, 2 एमबी तक, जो मेमोरी हीप में पृष्ठों की संख्या को काफी कम कर देगा। प्रौद्योगिकी में अंतर केवल इतना है कि विशाल पृष्ठों के लिए हमें पर्यावरण को स्पष्ट रूप से कॉन्फ़िगर करना चाहिए और कार्यक्रम को सिखाना चाहिए कि उनके साथ कैसे काम करना है, जबकि पारदर्शी विशाल पृष्ठ कार्यक्रमों के लिए "पारदर्शी रूप से" काम करते हैं।

टीएचपी और समस्या समाधान

यदि आपको ट्रांसपेरेंट विशाल पेजों के बारे में जानकारी है, तो आप खोज परिणामों में बहुत सारे पेज देख सकते हैं जिनमें "कैसे बंद करें"।

जैसा कि यह निकला, यह "कूल" फीचर Red Hat Corporation द्वारा लिनक्स कर्नेल में पेश किया गया था, इस सुविधा का सार यह है कि एप्लिकेशन मेमोरी के साथ पारदर्शी रूप से काम कर सकते हैं, जैसे कि वे वास्तविक विशाल पृष्ठ के साथ काम करते हैं। बेंचमार्क के अनुसार, THP अमूर्त एप्लिकेशन को 10% बढ़ाता है, आप प्रस्तुति में अधिक विवरण देख सकते हैं, लेकिन वास्तव में सब कुछ अलग है। कुछ मामलों में, टीएचपी सिस्टम में सीपीयू की खपत में अनुचित वृद्धि का कारण बनता है। अधिक जानकारी के लिए, Oracle की अनुशंसाएँ देखें।

हम जाते हैं और हमारे पैरामीटर की जांच करते हैं। जैसा कि यह निकला, THP डिफ़ॉल्ट रूप से चालू है, हम इसे कमांड से बंद करते हैं:

 echo never > /sys/kernel/mm/transparent_hugepage/enabled 

हम THP को बंद करने से पहले और लोड प्रोफ़ाइल पर, उसके बाद परीक्षण की पुष्टि करते हैं:

 setUp( MainScenario.inject( rampUsers(150) during (200 seconds)), Peak.inject( nothingFor(20 minutes), rampUsers(5000) during (30 minutes)) ).protocols(httpConfig) 

हमने टीएचपी को बंद करने से पहले इस तस्वीर को देखा

टीएचपी को बंद करने के बाद, हम पहले से ही कम संसाधन उपयोग का निरीक्षण कर सकते हैं।

मुख्य समस्या स्थानीयकृत थी। कारण ओएस में डिफ़ॉल्ट रूप से सक्षम था
पारदर्शी बड़े पृष्ठों की व्यवस्था। टीएचपी विकल्प को अक्षम करने के बाद, सिस्टम मोड में सीपीयू का उपयोग कम से कम 2 गुना कम हो गया, जिसने उपयोगकर्ता मोड के लिए संसाधनों को मुक्त कर दिया। मुख्य समस्या के विश्लेषण के दौरान, ओएस और रेडिस के नेटवर्क स्टैक के साथ बातचीत के "अड़चन" भी पाए गए, जो एक गहन अध्ययन का कारण है। लेकिन यह पूरी तरह से अलग कहानी है।

निष्कर्ष

अंत में, मैं प्रदर्शन समस्याओं की सफलतापूर्वक खोज के लिए कुछ सुझाव देना चाहूंगा:

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