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

ब्रेंडन ग्रेग, DTrace च्या विकसकांपैकी एक, जे सध्या Linux कर्नलमध्ये BPF-आधारित कार्यप्रदर्शन विश्लेषण साधने विकसित करत आहेत, Cassandra DBMS CentOS वरून Ubuntu मध्ये स्थलांतरित करताना Netflix ला आलेल्या कार्यप्रदर्शन समस्यांचे विश्लेषण करताना मिळालेल्या अनुभवाचा सारांश दिला. ऍमेझॉन EC2 क्लाउड Xen वर आधारित आहे. स्थलांतरानंतर, CPU लोड 30% ने वाढला आणि लेखन ऑपरेशन दरम्यान विलंब सुमारे समान प्रमाणात वाढला. हे दिसून येते की, वेळेच्या माहितीची तीव्रतेने विनंती करणार्‍या अनुप्रयोगांची कार्यक्षमता सिस्टीममध्ये निवडलेल्या अचूक वेळेच्या स्त्रोतावर अवलंबून असते.

सुरुवातीला, कार्यक्षमतेत घट होण्याचे कारण स्पष्ट नव्हते आणि निदान सुरू झाले की सतत चालू असलेल्या किंवा वेळोवेळी सुरू केलेल्या संसाधन-केंद्रित प्रणाली प्रक्रियेच्या संभाव्य प्रभावाचे निरीक्षण करून टॉप आणि एक्झेस्नूप युटिलिटीज वापरून सुरुवात केली. परंतु सर्व काही सूचित करते की जावामध्ये लिहिलेल्या कॅसॅंड्रा डीबीएमएसमध्ये संसाधनांचा वापर विशेषतः वाढला आहे. CentOS आणि Ubuntu वर समांतर चालू असलेल्या दोन Cassandra प्रक्रियांच्या प्रोफाइलिंग मेट्रिक्सची तुलना करून, समान क्वेरींवर प्रक्रिया करून, असे दिसून आले की एकूण वेळेपैकी सुमारे 32% वेळ os::javaTimeMillis(), ज्याचा वापर सध्याच्या वेळेबद्दल माहिती मिळविण्यासाठी केला जातो. .

यानंतर, एक प्रयोग आयोजित केला गेला ज्यामध्ये एक साधा Java ऍप्लिकेशन लिहिला गेला ज्याला System.currentTimeMillis() पद्धती म्हणतात लूपमध्ये शंभर दशलक्ष वेळा. अॅप्लिकेशन चालवताना दिसले की CentOS वर पूर्ण होण्यासाठी 13 सेकंद आणि उबंटूवर सुमारे 68 सेकंद लागले, म्हणजे. 5 पट हळू. एक समान प्रोग्राम C मध्ये लिहिलेला होता ज्याला gettimeofday() फंक्शन शंभर दशलक्ष वेळा संबोधले जाते, परंतु कार्यान्वित केल्यावर, समान परिणाम प्राप्त झाले.

हे स्पष्ट झाले की समस्येचे स्त्रोत वर्तमान वेळ परत करण्याचे कार्य होते, सिस्टममध्ये अचूक वेळेचे भिन्न स्त्रोत निवडताना निर्देशकांमधील बदलांकडे लक्ष वेधले गेले. “/sys/devices/system/clocksource/clocksource0/current_clocksource” च्या सामग्रीनुसार, अतिथी प्रणालीमध्ये Linux चालवताना “xen” टायमर डीफॉल्टनुसार वापरला जातो. वेळ स्त्रोत "tsc" मध्ये बदलल्यानंतर, उबंटूमधील चाचणी अनुप्रयोगाची अंमलबजावणी वेळ 68 ते 3.3 सेकंदांपर्यंत कमी झाली, म्हणजे. ते 20 पट वेगवान झाले. याव्यतिरिक्त, kvm-घड्याळ वेळ स्त्रोताची कार्यप्रदर्शन चाचणी घेण्यात आली, ज्याने TSC च्या तुलनेत 20% विलंब वाढ दर्शविला. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s वापरकर्ता 0m38.337. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench वास्तविक 29.875m0s वापरकर्ता 0m3.370s sys 0m3.353s

टीएससी स्त्रोत निवडताना वेळ मिळविण्यासाठी, आरडीटीएससी प्रोसेसर सूचना वापरल्या जातात, ज्याच्या अंमलबजावणीसाठी सिस्टम कॉलची आवश्यकता नसते (सूचनांना उन्नत विशेषाधिकारांची आवश्यकता नसते आणि सीपीयूमध्ये तयार केलेल्या टाइम काउंटरमधून मूल्य तयार करते). डीफॉल्टनुसार, टीएससी सक्रिय केले जात नाही कारण जुन्या दिवसांमध्ये या स्त्रोताने हळूहळू टाइम ड्रिफ्ट वगळले नाही, जे इतर प्रोसेसरमध्ये अधिक अचूक वाचन मिळविण्यासाठी सॉफ्टवेअरद्वारे समायोजित केले जाते. प्रोसेसर डेव्हलपमेंटमध्ये तज्ञ असलेल्या एका अभियंत्याच्या मते, TSC वापरताना वेळ बदलण्याची भीती फार पूर्वीपासून असत्य आहे आणि आधुनिक प्रोसेसरमध्ये हा स्त्रोत वर्षानुवर्षे स्थिर वाचन तयार करू शकतो.

नेटफ्लिक्समधील उत्पादन सर्व्हरला TSC स्त्रोतावर स्विच केल्याने लेखन विलंबामध्ये 43% घट झाली आणि उबंटू वापरून परिणाम प्राप्त झाले जे सेंटोस चालवणाऱ्या कॉन्फिगरेशनपेक्षा 4 पट अधिक वेगवान होते. अभ्यासाचे परिणाम Amazon वर हस्तांतरित केले गेले, ज्याने अधिकृतपणे Xen हायपरवाइजरवर आधारित AWS EC2 वातावरणात डीफॉल्ट TSC वेळ स्रोत वापरण्याची शिफारस केली (केव्हीएम-घड्याळाची शिफारस नायट्रो हायपरवाइजरवर आधारित वातावरणात केली जाते).

स्त्रोत: opennet.ru