कई लोगों को अपने दम पर कुछ लिखने और लिखने की संभावना पर संदेह है। अक्सर कीमत बहुत अधिक होती है। अपने खुद के JDK के बारे में सुनना विशेष रूप से अजीब है, जो माना जाता है कि हर काफी बड़ी कंपनी में हैं। वसा के साथ नरक क्या हैं? यह लेख कंपनी के बारे में एक विस्तृत कहानी होगी, जो यह सब वास्तविक वाणिज्यिक लाभ लाती है, और जिसने एक भयानक काम किया, क्योंकि वे:

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

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

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

स्लाइड और रिपोर्ट का वर्णन (आपको उनकी आवश्यकता नहीं है, इस हैब्रोटोपाइक में वह सब कुछ है जिसकी आपको आवश्यकता है)।

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

लेकिन पहले भाग पर जाने से पहले, मैं आपको हमारी कंपनी के बारे में संक्षेप में बताना चाहूंगा।

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

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

ऊपर की तस्वीर में आप एक चित्र देखते हैं जो हमारे समर्थन प्रणाली पर लोड दिखाता है। लाल रेखा हमारी ऑर्डर सेवा का काम दिखाती है और प्रति सेकंड लेनदेन की चरम संख्या दिखाती है, पिछले साल यह 325 हजार थी। ब्लू लाइन भुगतान सेवा को संदर्भित करती है, और उसके पास यह आंकड़ा 256 हजार है। मैं इस बात के बारे में बात करना चाहूंगा कि इतने सारे लेनदेन की सेवा करने वाले स्टैक को कैसे अनुकूलित किया जाए।

आइए मुख्य तकनीकों पर चर्चा करें जो जावा के साथ अलीबाबा में काम करती हैं। सबसे पहले, मुझे यह कहना होगा कि हमारे पास आधार के रूप में कई ओपन सोर्स एप्लिकेशन हैं। बड़े डेटा प्रोसेसिंग के लिए हम HBase Hadoop का उपयोग करते हैं। एक कंटेनर के रूप में हम टॉमकैट और ओएसजीआई का उपयोग करते हैं। जावा का उपयोग बड़े पैमाने पर किया जाता है - हमारे डेटा सेंटर में लाखों जेवीएम इंस्टैंस तैनात किए जाते हैं। यह भी कहा जाना चाहिए कि हमारी वास्तुकला सेवा-उन्मुख है, अर्थात हम कई ऐसी सेवाएँ बनाते हैं जो RPC कॉल का उपयोग करते हुए एक-दूसरे के साथ संचार करती हैं। अंत में, हमारी वास्तुकला विषम है। प्रदर्शन में सुधार करने के लिए, कई एल्गोरिदम सी और सी ++ पुस्तकालयों का उपयोग करके लिखे गए हैं, इसलिए वे जेएनआई कॉल का उपयोग करके जावा के साथ संवाद करते हैं।

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

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

तीसरी कठिनाई यह है कि हमारे पास बहुत सारे अनुप्रयोग चल रहे हैं। मुझे लगता है कि यहां हर कोई ऐसे टूल्स से परिचित है जो OpenJDK के साथ आते हैं, जैसे JConsole या VisualVM। समस्या यह है कि वे हमें सटीक जानकारी नहीं देते हैं जिन्हें हमें कॉन्फ़िगर करने की आवश्यकता है। इसके अलावा, जब हम उत्पादन में इन उपकरणों (उदाहरण के लिए, JConsole या VisualVM) का उपयोग करते हैं, तो कम ओवरहेड केवल एक इच्छा नहीं है, बल्कि एक आवश्यक आवश्यकता है। मुझे अपने डायग्नोस्टिक टूल लिखने थे।

चित्र OpenJDK में किए गए परिवर्तनों की रूपरेखा प्रस्तुत करता है। आइए एक नजर डालते हैं कि हमने उन कठिनाइयों को कैसे काबू किया जो मैंने ऊपर बताई थी।

मल्टी-टेनेंट जेवीएम

एक समाधान हम एक बहु-किरायेदार जेवीएम कहते हैं। यह आपको एक कंटेनर में कई वेब एप्लिकेशन सुरक्षित रूप से चलाने की अनुमति देता है। एक अन्य समाधान GCIH (GC अदृश्य ढेर) कहा जाता है। यह एक ऐसा तंत्र है जो आपको पूर्ण विकसित जावा ऑब्जेक्ट प्रदान करता है, जो एक ही समय में कचरा संग्रह की लागत की आवश्यकता नहीं है। इसके अलावा, धागा संदर्भों की लागत को कम करने के लिए, हमने अपने जावा प्लेटफ़ॉर्म पर कोरआउट्स को लागू किया। इसके अलावा, हमने JWarmup नाम का एक तंत्र लिखा है - इसका कार्य रेडीनो के समान है। डगलस हॉकिंस ने अपनी रिपोर्ट में उनका उल्लेख किया है । अंत में, हमने अपना स्वयं का प्रोफाइलिंग उपकरण ZProfiler विकसित किया।

आइए हम OpenJDK- आधारित मल्टी-टेनेंसी को कैसे कार्यान्वित करते हैं, इस पर एक नज़र डालें

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

तस्वीर योजनाबद्ध रूप से दिखाती है कि हम इसे कैसे लागू करते हैं। हम JVM के अंदर किरायेदारों के लिए कई कंटेनर बनाते हैं। इनमें से प्रत्येक कंटेनर प्रत्येक जावा मॉड्यूल के लिए विश्वसनीय संसाधन खपत नियंत्रण प्रदान करता है। एक कंटेनर में कई मॉड्यूल तैनात किए जा सकते हैं। प्रत्येक मॉड्यूल रनटाइम में एक थ्रेड या थ्रेड्स के समूह के साथ जुड़ा हो सकता है।

आइए नजर डालते हैं कि किरायेदार कंटेनर एपीआई कैसा दिखता है। हमारे पास एक किरायेदार कॉन्फ़िगरेशन क्लास है जो संसाधन खपत के बारे में जानकारी संग्रहीत करता है। अगला, खुद कंटेनर का एक वर्ग है।

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

विचार करें कि एक किरायेदार थ्रेड के साथ कैसे इंटरैक्ट करता है। TenantContainer वर्ग TenantContainer .run() विधि प्रदान करता है, और जब कोई थ्रेड इसमें प्रवेश करता है, तो यह स्वचालित रूप से किरायेदार से TenantContainer जाता है, और जब वह इसे छोड़ता है, तो रिवर्स प्रक्रिया होती है। इसलिए सभी कोड .run() विधि के अंदर निष्पादित किए जाते हैं। इसके अलावा, .run() विधि के अंदर बनाया गया कोई भी धागा मूल धागा के किरायेदार से जुड़ा होता है।

हम एक बहुत महत्वपूर्ण सवाल पर आए - सीपीयू को बहु-किरायेदार जेवीएम में कैसे प्रबंधित किया जाता है? हमारा समाधान अभी लिनक्स x64 प्लेटफॉर्म पर लागू किया गया है। एक नियंत्रण समूह तंत्र, cgroups मौजूद है। यह आपको एक अलग समूह में एक प्रक्रिया का चयन करने की अनुमति देता है, और फिर प्रत्येक समूह के लिए संसाधन खपत का आपका तरीका इंगित करता है। आइए इस दृष्टिकोण को हॉटस्पॉट जेवीएम के संदर्भ में स्थानांतरित करने का प्रयास करें। हॉटस्टॉप में, जावा थ्रेड्स को मूल थ्रेड्स के रूप में व्यवस्थित किया जाता है।

यह ऊपर दिए गए आरेख में दिखाया गया है: प्रत्येक जावा धागा मूल धागे के साथ एक-से-एक पत्राचार में है। हमारे उदाहरण में, हमारे पास एक TenantA कंटेनर है, जिसमें दो देशी धागे हैं। सीपीयू समय के वितरण को नियंत्रित करने में सक्षम होने के लिए, हम दोनों मूल धागे को एक नियंत्रण समूह में रखते हैं। इसके कारण, हम संसाधनों की खपत को नियंत्रित कर सकते हैं, [नियंत्रण समूहों] की कार्यक्षमता पर पूरी तरह निर्भर हैं () https://en.wikipedia.org/wiki/Cgroups )।

आइए एक अधिक विस्तृत उदाहरण देखें।

लिनक्स पर नियंत्रण समूहों को एक निर्देशिका में मैप किया जाता है। हमारे उदाहरण में, हमने किरायेदार 0. के लिए /t0 निर्देशिका बनाई। इस निर्देशिका में /t0/tasks निर्देशिका शामिल है, t0 लिए सभी धागे यहां स्थित होंगे। एक अन्य महत्वपूर्ण फ़ाइल /t0/cpu.shares । यह इंगित करता है कि सीपीयू को इस किरायेदार को कितना समय दिया जाएगा। यह पूरी संरचना नियंत्रण समूहों से विरासत में मिली है - हमने जावा धागा, मूल धागा और नियंत्रण समूह के बीच सीधे पत्राचार सुनिश्चित किया है।

एक अन्य महत्वपूर्ण मुद्दा प्रत्येक किरायेदार के एक समूह के प्रबंधन से संबंधित है।

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

योजनाबद्ध रूप से, इस प्रक्रिया को ऊपर चित्र में दर्शाया गया है। जैसा कि मैंने कहा, हमारा कार्यान्वयन G1GC पर आधारित है। G1GC एक कॉपी करने वाला कचरा संग्रहकर्ता है, इसलिए कचरा संग्रहण के दौरान हमें यह सुनिश्चित करने की आवश्यकता है कि ऑब्जेक्ट को ढेर के सही अनुभाग में कॉपी किया गया है। स्लाइड पर, Tenant-1 द्वारा बनाई गई सभी वस्तुओं को Tenant-2 समान ढेर के अपने हिस्से में कॉपी किया जाना चाहिए।

ऐसे अन्य विचार हैं जो तब उत्पन्न होते हैं जब किरायेदारों को एक दूसरे से अलग किया जाता है। यहाँ मुझे TLAB (थ्रेड लोकल एलोकेशन बफ़र) के बारे में कहना चाहिए - मेमोरी के तेजी से आवंटन के लिए एक तंत्र। TLAB स्थान ढेर अनुभाग पर निर्भर करता है। जैसा कि मैंने कहा, अलग-अलग किरायेदारों के ढेर वर्गों के अलग-अलग समूह हैं।

TLAB के साथ काम करने की बारीकियों को स्लाइड पर दिखाया गया है - जब थ्रेड Tenant 1 से Tenant 2 तक स्विच करता है, तो हमें यह सुनिश्चित करने की आवश्यकता है कि टीएलएबी स्पेस के लिए सही हीप सेक्शन का उपयोग किया जाए। इसे दो तरह से हासिल किया जा सकता है। पहला तरीका यह है कि Thread A Tenant 1 से Tenant 2 तक स्विच करता है, हम बस पुराने से छुटकारा पाते हैं और Tenant 2 में एक नया निर्माण करते हैं। इस विधि को लागू करना अपेक्षाकृत आसान है, लेकिन यह TLAB में जगह बर्बाद करता है, जो अवांछनीय है। दूसरा तरीका अधिक जटिल है - टीएलएबी को किरायेदारों से अवगत कराना। इसका मतलब है कि हमारे पास एक धागे के लिए कई TLAB बफ़र्स होंगे। जब Thread A Tenant 1 से Tenant 2 तक स्विच करता है, तो हमें बफर को बदलने और Tenant 2 में बनाए गए उपयोग करने की आवश्यकता है।

एक अन्य तंत्र जिसे किरायेदारों के परिसीमन के संबंध में कहा जाना चाहिए, वह है IHOP (थ्रेडिंग ऑक्यूपेंसी पेरेंट शुरू करना)। प्रारंभ में, IHOP की गणना पूरे ढेर के आधार पर की गई थी, लेकिन एक बहुपरत तंत्र के मामले में, यह ढेर के केवल एक खंड के आधार पर गणना की जानी चाहिए।

चलो GCIH (GC अदृश्य ढेर) क्या है पर एक करीब से देखो। यह तंत्र कचरे के संग्रह से छिपे हुए, ढेर पर एक खंड बनाता है, और तदनुसार, कचरा संग्रह से प्रभावित नहीं होता है। इस साइट का प्रबंधन GCIH किरायेदार द्वारा किया जाता है।

यहां यह कहना महत्वपूर्ण है कि हम अपने जावा डेवलपर्स को एक सार्वजनिक एपीआई प्रदान करते हैं। इसके साथ काम करने का एक उदाहरण स्क्रीन पर देखा जा सकता है। यह एक नियमित रूप से ढेर से GCIH ढेर के एक हिस्से में ले जाने के लिए MoveIn moveIn() विधि का उपयोग करने की अनुमति देता है। इसका लाभ यह है कि आप अभी भी इन वस्तुओं के साथ नियमित जावा वस्तुओं के साथ बातचीत कर सकते हैं, वे संरचना में बहुत समान हैं। लेकिन साथ ही उन्हें कचरा संग्रहण की लागत की आवश्यकता नहीं होती है। मेरे विचार में निष्कर्ष यह है कि यदि आप कचरा संग्रहण में तेजी लाना चाहते हैं, तो आपको अपने आवेदन की आवश्यकताओं के अनुसार कचरा संग्रहकर्ता के व्यवहार को अनुकूलित करना होगा।

तस्वीर एक उच्च-स्तरीय GCIH योजना दिखाती है। दाईं ओर एक नियमित जावा हीप है, बाईं ओर GCIH के लिए आवंटित स्थान है। GCIH में एक नियमित ढेर से वस्तुओं के लिंक मान्य हैं, लेकिन GCIH से एक नियमित ढेर के लिंक नहीं हैं। यह समझने के लिए कि ऐसा क्यों है, एक उदाहरण पर विचार करें। जीसीआईएच में हमारे पास ऑब्जेक्ट "ए" है, जिसमें एक नियमित ढेर में ऑब्जेक्ट "बी" का संदर्भ है। समस्या यह है कि ऑब्जेक्ट बी को कचरा कलेक्टर द्वारा स्थानांतरित किया जा सकता है। जैसा कि मैंने पहले ही कहा था, हम GCIH में अपडेट नहीं करते हैं, इसलिए कचरा संग्रहकर्ता के काम करने के बाद, ऑब्जेक्ट "A" में ऑब्जेक्ट "B" का एक अमान्य संदर्भ हो सकता है। पूर्व-लेखन बाधा का उपयोग करके इस समस्या को हल किया जा सकता है - पिछली रिपोर्ट में उन पर चर्चा की गई थी। उदाहरण के लिए, मान लें कि किसी व्यक्ति को नियमित जावा हीप से लिंक को बचाने के लिए GCIH से पहले बचाने की जरूरत है जो हमने मान लिया था कि एक संकेतक ध्वज के साथ एक पूर्वसूचक अपवाद का परिणाम होगा कि नियम का उल्लंघन किया गया था।

एक विशिष्ट एप्लिकेशन के लिए, एक बहु-किरायेदार JVM का उपयोग हमारे Taobao निजीकरण प्लेटफ़ॉर्म में संक्षिप्त रूप में किया जाता है। यह हमारे ई-शॉपिंग एप्लिकेशन के लिए एक सिफारिश प्रणाली है। टीपीपी एक कंटेनर में कई माइक्रोसर्विस को तैनात कर सकता है, और बहु-किरायेदार जेवीएम की मदद से हम प्रत्येक माइक्रोसेवर को प्रदान की जाने वाली मेमोरी और सीपीयू समय को नियंत्रित करते हैं।

GCIH के लिए, यह हमारे अन्य सिस्टम, UM प्लेटफ़ॉर्म में उपयोग किया जाता है। यह एक ऑनलाइन डिस्काउंटिंग एप्लीकेशन है। इस एप्लिकेशन का मालिक GCIH का उपयोग स्थानीय मशीन पर GCIH डेटा को प्री-कैश करने के लिए करता है, ताकि रिमोट कैश सर्वर या रिमोट डेटाबेस पर ऑब्जेक्ट्स तक नहीं पहुंच सके। नतीजतन, हम नेटवर्क पर लोड को कम करते हैं और कम क्रमांकन और डीरियलाइज़ेशन करते हैं।

तस्वीर एक आरेख दिखाती है जिसमें एक पारंपरिक जेडीके और लाल - जीसीआईएच का उपयोग करते समय नीला रंग लोड दिखाता है। जैसा कि आप देख सकते हैं, हम 18% से अधिक CPU उपयोग को कम कर रहे हैं।

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

जावा में Coroutines

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

एक उदाहरण पर विचार करें जिसमें हमारे पास आपके आवेदन के तर्क के साथ 4 I / O धागे और 200 धागे होंगे। स्क्रीन पर तालिका इस सरल डेमो को शुरू करने के परिणामों को दिखाती है - आप देख सकते हैं कि सीपीयू को संदर्भों को बदलने में कितना समय लगता है। इस समस्या का समाधान जावा में कोरुटिन का कार्यान्वयन हो सकता है।

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

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

जैसा कि आप स्लाइड पर दिखाए गए धागे के डंप से देख सकते हैं, हम एक धागे में दो कोरटाइन बनाते हैं, और दो धागे नहीं। अब आपको इस समाधान को काम करने की आवश्यकता है। यहाँ मुख्य बात यह है कि सभी संभावित अवरोधन बिंदुओं पर यील्डटीओ इवेंट जनरेशन बनाना है। हमारे उदाहरण में, ये बिंदु serverSocket.accept() , is.read(buf) , एक सॉकेट कनेक्शन और os.write(buf) । इन बिंदुओं पर घटनाओं का उत्पादन करने के लिए धन्यवाद, हम एक ही धागे के भीतर एक कोरटाइन से दूसरे में नियंत्रण स्थानांतरित करने में सक्षम होंगे। संक्षेप में, हमारा दृष्टिकोण यह है कि हम coroutine का उपयोग करके अतुल्यकालिक प्रदर्शन प्राप्त करते हैं, लेकिन हमारे प्रोग्रामर एक समकालिक शैली में कोड लिख सकते हैं, क्योंकि ऐसा कोड बहुत सरल और बनाए रखने और डिबग करने में आसान है।

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

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

आइए आगे बढ़ते हैं कि हमने कॉरआउट के लिए उपयोगकर्ता-मोड शेड्यूलर को कैसे लागू किया। हम एक चयनकर्ता का उपयोग करते हैं, और इसके साथ हम कई चैनल पंजीकृत करते हैं। जब कोई I / O ईवेंट (सॉकेट पढ़ता है, सॉकेट लिखना, सॉकेट कनेक्ट या सॉकेट स्वीकार करना) होता है, तो इसे चयनकर्ता के लिए एक कुंजी के रूप में लिखा जाता है। इसलिए, इस घटना के अंत में, हम चयनकर्ता से एक चेतावनी प्राप्त करते हैं। इस प्रकार, हम एक चयनकर्ता का उपयोग I / O लॉक होने की स्थिति में कोरआउट करने की योजना बनाते हैं। एक उदाहरण पर विचार करें कि यह कैसे काम करेगा।

तस्वीर में हम सॉकेट और तुल्यकालिक कॉल client.read(buffer) । स्लाइड के नीचे कोड लिखा होता है जिसे इस कॉल के अंदर निष्पादित किया जाएगा। सबसे पहले, यह जांचता है कि चैनल से पढ़ना संभव है या नहीं। यदि ऐसा है, तो हम परिणाम लौटाते हैं। सबसे दिलचस्प बात यह है कि अगर पढ़ा नहीं जा सकता है। फिर हम चयनकर्ता के साथ हमारे शेड्यूलर में रीड इवेंट को पंजीकृत करते हैं। इससे किसी अन्य कोरआउट के निष्पादन की योजना बनाना संभव हो जाता है। एक नज़र डालिए कि ऐसा कैसे होता है। हमारे पास एक धागा है जिसमें एक अनुसूचक बनाया गया है। धागा और हमारे कोरटाइन एक-दूसरे के साथ एक-से-एक पत्राचार में हैं। शेडयूलर हमें इस धागे के कोरटाइन का प्रबंधन करने की अनुमति देता है। यदि I / O अवरुद्ध है तो क्या होगा? जब I / O ईवेंट होते हैं, तो शेड्यूलर को एक अलर्ट प्राप्त होता है, और इस स्थिति में वह पूरी तरह से चयनकर्ता पर निर्भर करता है। इस तरह के एक आयोजन के बाद, शेड्यूलर को अगले उपलब्ध कोरटाइन की योजना बनाने का अवसर मिलता है।

आइए अपने शेड्यूलर के अवलोकन को संक्षेप में प्रस्तुत करें, जिसे हमने WispEngine कहा है। हमारे प्रत्येक धागे के लिए, हम एक अलग WispEngine आवंटित करते हैं। जब एक coroutine लॉक होता है, तो हम WispEngine का उपयोग करके कुछ ईवेंट (सॉकेट रीड / राइट वगैरह) लॉग करते हैं। कुछ घटनाएं थ्रेड पार्किंग से संबंधित हैं, उदाहरण के लिए, यदि आप 100 मिलीसेकेंड की देरी के साथ thread.sleep() कहते हैं। इस स्थिति में, आपके लिए एक थ्रेड पार्किंग ईवेंट जनरेट किया जाएगा, जिसे तब चयनकर्ता में पंजीकृत किया जाएगा। एक अन्य महत्वपूर्ण मुद्दा यह है कि जब शेड्यूलर अगले उपलब्ध कोरटाइन को नियुक्त करता है। दो मुख्य शर्तें हैं। पहला यह है कि जब कुछ घटनाएं उत्पन्न होती हैं, जैसे कि I / O इवेंट या टाइमआउट इवेंट। यहां सब कुछ बहुत सरल है: मान लीजिए कि आप 200 मिलीसेकेंड की देरी के साथ thread.sleep() को कॉल करते हैं। जब वे समाप्त हो जाते हैं, तो शेड्यूलर के पास अगले उपलब्ध कोरटाइन को निष्पादित करने का अवसर होता है। या यहाँ हम कुछ object.notify() घटनाओं के बारे में बात कर सकते हैं, जो कहती हैं कि, object.notify() या object.notifyAll() कहकर उत्पन्न होती हैं, दूसरी शर्त यह है कि जब उपयोगकर्ता नए अनुरोध सबमिट करता है, और हम आपके अनुरोधों को पूरा करने के लिए एक coroutine बनाते हैं, और तब sheduler असाइन करता है इसका कार्यान्वयन।

यहां आपको हमारे द्वारा बनाई गई सेवा, WispThreadExecutor के बारे में भी कहना होगा।

एक उदाहरण कोड स्क्रीन पर प्रस्तुत किया गया है, और हम देखते हैं कि यह एक नियमित ExecutorService है, उसी तरह बनाया गया है। .execute() और submit() तरीके .execute() करने योग्य कार्यों के लिए उपलब्ध हैं, लेकिन समस्या यह है कि submit() विधि से गुजरने वाले सभी रन करने योग्य कार्यों को कोरटीन में निष्पादित किया जाएगा, और थ्रेड में नहीं। यह समाधान उन लोगों के लिए पूरी तरह से पारदर्शी है जो हमारे आवेदन को लागू करेंगे, वे हमारे एपीआई को कोरआउट्स के लिए उपयोग करने में सक्षम होंगे।

मैं पोस्ट के अंतिम मुश्किल हिस्से में आता हूं - कोरटाइन में सिंक्रोनाइज़ेशन के मुद्दे को कैसे हल किया जाए। यह एक जटिल प्रश्न है, तो आइए इसे एक सरलीकृत उदाहरण के साथ देखें। यहाँ हमारे पास coroutine A ( test::foo ) और corutin ( test::bar ) है। सबसे पहले, हम test:foo के निष्पादन को नियत करते हैं test:foo to coroutine Corutin wait() कहता है। यदि कुछ भी नहीं किया जाता है, तो wait() करने के लिए कॉल द्वारा वर्तमान धागा अवरुद्ध हो जाएगा wait() । जैसा कि धागे के इस डंप से देखा जा सकता है, एक गतिरोध उत्पन्न होगा, और हम अगले coroutine को असाइन नहीं कर पाएंगे।

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

चलो एक और अधिक जटिल मामले के बारे में बात करते हैं - फुलाया हुआ ताला। आइए हम फिर से उस उदाहरण को देखें जो मैंने ऊपर उद्धृत किया था। हमारे पास Corutin ( .foo() ) और Corutin B ( .bar() ) हैं। सबसे पहले, हम कोरटाइन के निष्पादन को असाइन करते हैं और इसे शुरू करते हैं। फिर इसे Object.wait कहते हैं, जिसके बाद यह प्रतीक्षा सूची में आ जाता है। उसके बाद, हम एक बहुत ही महत्वपूर्ण कदम उठाते हैं: हम yieldTo घटना उत्पन्न करते हैं, जो नियंत्रण को मुख्य धागे में स्थानांतरित करता है। इसके बाद, हम कोरुटिन B शुरू करते हैं B यह Object.notify कहता है, और इसी unpark घटनाओं unpark कर रहे unpark । वे अंततः कोरआउट जगाएंगे bar() , नियंत्रण को कोरटाइन स्थानांतरित करना संभव होगा इस प्रकार, मैंने पहले जिस गतिरोध का उल्लेख किया है वह पूरी तरह से दूर हो गया है।

आइए अब प्रदर्शन पर चर्चा करें। हम अपने कार्ट में से एक ऑनलाइन एप्लिकेशन में कॉरआउट का उपयोग करते हैं। इसके आधार पर, हम नियमित JDK के काम के साथ कोरुटिन के काम की तुलना कर सकते हैं।

जैसा कि आप देख सकते हैं, वे हमें प्रोसेसर समय की खपत को लगभग 10% कम करने की अनुमति देते हैं। मैं समझता हूं कि आपमें से अधिकांश के पास सीधे JDK कोड में इस तरह के जटिल बदलाव करने की क्षमता नहीं है। लेकिन मेरी राय में, मुख्य निष्कर्ष यह है कि यदि उत्पादकता में हानि होती है, तो धनराशि खर्च होती है और परिणामी राशि काफी बड़ी होती है, आप कोरटीन लाइब्रेरी का उपयोग करके उत्पादकता में सुधार करने का प्रयास कर सकते हैं।

JWarmup

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

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

आइए अधिक विस्तार से देखें कि हम किस प्रकार की जानकारी एकत्र करते हैं। हमें यह लिखने की जरूरत है कि कौन सी कक्षाएं आरम्भिक हैं, कौन से तरीके संकलित किए गए हैं, फिर इस डेटा को हार्ड ड्राइव पर लॉग में फ्लश किया जाता है, जो संकलक के लिए सुलभ है। सबसे कठिन क्षण कक्षाओं का प्रारंभिककरण है।इसका आदेश पूरी तरह से एप्लिकेशन लॉजिक पर निर्भर है। स्लाइड एक उदाहरण दिखाती है - Barनिष्पादन के बाद वर्ग आरंभीकरण होना चाहिए Foo.test(), जैसा कि यह उपयोग करता है foo.count। इस स्थिति में, हम उस समय आरंभीकरण करते हैं जब सभी आवश्यक तर्क पहले से ही पूरे हो चुके होते हैं।

JWarmup (tiered compilation), . , — CPU. JWarmup , CPU, JDK. , , JDK. , , .

JWarmup. , , , groovy-, Java-, . . , , «null check elimination». . , JWarmup , JWarmup, .

, Alibaba.

. JVM — , , . Java-, metaspace, VM ( VM) JIT-. OpenJDK. -, , . -, . HotMethodProfiling, , CPU. , , Honest Profiler , , , HotMethodProfiling. MethodTracing. , , . , metaspace . Java-, . metaspace , . Java.

, , ZProfiler.

. JVMTi, JVM ( ). , ZProfiler Apache Tomcat. -. ZProfiler JVM. , ZProfiler -UI, . ZProfiler . -, UI JVM. -, ZProfiler post-mortem . , OutOfMemoryError, , JVM ZProfiler, . , , , Eclipse MAT.

. . JVM, GCIH, Alibaba JDK, JWarmup — , ReadyNow Zing JVM. , ZProfiler. , , OpenJDK. , , JWarmup OpenJDK. , OpenJDK Loom, Java. , .

. , , JPoint 2018 . 2019 , JPoint , 5-6 . , Rafael Winterhalter Sebastian Daschner. . , YouTube . JPoint!