सिस्टम में चयनित समय स्रोत के प्रदर्शन प्रभाव का विश्लेषण

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

सबसे पहले, प्रदर्शन में कमी का कारण स्पष्ट नहीं था और निदान शीर्ष और निष्पादन उपयोगिताओं का उपयोग करके लगातार चलने वाले या समय-समय पर लॉन्च किए गए संसाधन-गहन सिस्टम प्रक्रियाओं के संभावित प्रभाव की निगरानी के साथ शुरू हुआ। लेकिन सब कुछ इंगित करता है कि संसाधन खपत विशेष रूप से जावा में लिखे कैसेंड्रा डीबीएमएस में बढ़ गई थी। CentOS और Ubuntu पर समानांतर में चलने वाली दो कैसेंड्रा प्रक्रियाओं की प्रोफाइलिंग मेट्रिक्स की तुलना करने पर, समान प्रश्नों को संसाधित करने से पता चला कि कुल समय का लगभग 32% os::javaTimeMillis() को कॉल करने में व्यतीत हुआ, जिसका उपयोग वर्तमान समय के बारे में जानकारी प्राप्त करने के लिए किया जाता है। .

इसके बाद, एक प्रयोग किया गया जिसमें एक सरल जावा एप्लिकेशन लिखा गया जिसे एक लूप में एक सौ मिलियन बार System.currentTimeMillis() विधि कहा गया। एप्लिकेशन को चलाने से पता चला कि CentOS पर इसे पूरा होने में 13 सेकंड लगे, और Ubuntu पर लगभग 68 सेकंड लगे, यानी। 5 गुना धीमी. इसी तरह का एक प्रोग्राम C में लिखा गया था जिसे gettimeofday() फ़ंक्शन को सौ मिलियन बार कॉल किया गया था, लेकिन जब निष्पादित किया गया, तो समान परिणाम प्राप्त हुए।

चूंकि यह स्पष्ट हो गया कि समस्या का स्रोत वर्तमान समय को वापस करने का कार्य था, सिस्टम में सटीक समय के विभिन्न स्रोतों को चुनते समय संकेतकों में बदलाव पर ध्यान दिया गया। "/sys/devices/system/क्लॉकसोर्स/क्लॉकसोर्स0/करंट_क्लॉकसोर्स" की सामग्री को देखते हुए, अतिथि सिस्टम में लिनक्स चलाते समय "xen" टाइमर का उपयोग डिफ़ॉल्ट रूप से किया गया था। समय स्रोत को "tsc" में बदलने के बाद, उबंटू में परीक्षण एप्लिकेशन का निष्पादन समय 68 से घटकर 3.3 सेकंड हो गया, यानी। यह 20 गुना तेज हो गया. इसके अतिरिक्त, केवीएम-क्लॉक समय स्रोत का एक प्रदर्शन परीक्षण किया गया, जिसमें टीएससी की तुलना में देरी में 20% की वृद्धि देखी गई। $ cat /sys/devices/system/क्लॉकसोर्स/क्लॉकसोर्स0/उपलब्ध_क्लॉकसोर्स xen tsc hpet acpi_pm $ cat /sys/devices/system/क्लॉकसोर्स/क्लॉकसोर्स0/current_locksource xen $ समय जावा टाइमबेंच वास्तविक 1m8.300s उपयोगकर्ता 0m38.337s sys 0m29.875s $ इको टीएससी > /sys/डिवाइसेज/सिस्टम/क्लॉकसोर्स/क्लॉकसोर्स0/करंट_क्लॉकसोर्स $ समय जावा टाइमबेंच वास्तविक 0m3.370s उपयोगकर्ता 0m3.353s sys 0m0.026s

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

नेटफ्लिक्स पर उत्पादन सर्वर को टीएससी स्रोत पर स्विच करने से लेखन विलंबता में 43% की कमी आई और उबंटू का उपयोग करके परिणाम प्राप्त हुए जो "एक्सईएन" समय स्रोत के साथ सेंटओएस चलाने वाले कॉन्फ़िगरेशन की तुलना में 4 गुना तेज थे। अध्ययन के नतीजे अमेज़ॅन को स्थानांतरित कर दिए गए, जिसने आधिकारिक तौर पर ज़ेन हाइपरवाइज़र के आधार पर एडब्ल्यूएस ईसी 2 वातावरण में डिफ़ॉल्ट टीएससी समय स्रोत का उपयोग करने की सिफारिश की (केवीएम-क्लॉक नाइट्रो हाइपरवाइज़र के आधार पर वातावरण में अनुशंसित रहता है)।

स्रोत: opennet.ru