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

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

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

यस पछि, एउटा प्रयोग गरिएको थियो जसमा एउटा साधारण जाभा अनुप्रयोग लेखिएको थियो जसलाई System.currentTimeMillis() विधि भनिन्छ एक लूपमा एक करोड पटक। एप्लिकेसन चलाउँदा CentOS मा पूरा गर्न 13 सेकेन्ड र Ubuntu मा लगभग 68 सेकेन्ड लाग्यो, अर्थात्। 5 पटक ढिलो। एउटा समान कार्यक्रम C मा लेखिएको थियो जुन gettimeofday() प्रकार्यलाई सय मिलियन पटक भनिन्छ, तर जब कार्यान्वयन गरियो, समान परिणामहरू प्राप्त गरियो।

यो समस्याको स्रोत वर्तमान समय फिर्ता गर्ने प्रकार्य थियो भनेर स्पष्ट भएकोले, प्रणालीमा सही समयको विभिन्न स्रोतहरू छनौट गर्दा ध्यान संकेतकहरूमा परिवर्तनहरूमा फर्कियो। "/sys/devices/system/clocksource/clocksource0/current_clocksource" को सामाग्रीहरू द्वारा न्याय गर्दै, "xen" टाइमर अतिथि प्रणालीमा Linux चलाउँदा पूर्वनिर्धारित रूपमा प्रयोग गरिएको थियो। समय स्रोतलाई "tsc" मा परिवर्तन गरेपछि, Ubuntu मा परीक्षण अनुप्रयोगको कार्यान्वयन समय 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 $ समय java TimeBench वास्तविक 1m8.300s प्रयोगकर्ता 0m38.337. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench वास्तविक 29.875m0s प्रयोगकर्ता 0m3.370s sys 0m3.353s

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

नेटफ्लिक्समा उत्पादन सर्भरहरू TSC स्रोतमा स्विच गर्दा लिखित विलम्बतामा 43% कमी आयो र Ubuntu प्रयोग गरेर परिणामहरू प्राप्त भयो जुन "xen" समय स्रोतको साथ CentOS चलिरहेको कन्फिगरेसनहरू भन्दा 4 गुणा छिटो थियो। अध्ययनको नतिजाहरू Amazon मा हस्तान्तरण गरिएको थियो, जसले आधिकारिक रूपमा Xen हाइपरभाइजरमा आधारित AWS EC2 वातावरणमा पूर्वनिर्धारित TSC समय स्रोत प्रयोग गर्न सिफारिस गरेको थियो (kvm-घडी नाइट्रो हाइपरवाइजरमा आधारित वातावरणमा सिफारिस गरिएको छ)।

स्रोत: opennet.ru