ClickHouse में क्वेरी प्रदर्शन विश्लेषण। यैंडेक्स रिपोर्ट

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



जब भी मैं अनुरोध करता हूं, मैं न केवल परिणाम से चिंतित हूं, बल्कि यह भी कहता हूं कि यह अनुरोध क्या करता है। उदाहरण के लिए, यह एक सेकंड के लिए काम करता है। यह बहुत है या थोड़ा है? मैं हमेशा सोचता हूं: आधा सेकंड क्यों नहीं? फिर मैं कुछ का अनुकूलन करता हूं, इसे गति देता हूं, और यह 10 एमएस के लिए काम करता है। मैं आमतौर पर संतुष्ट हूं। लेकिन फिर भी, इस मामले में मैं एक नाराज चेहरे की अभिव्यक्ति बनाने की कोशिश करता हूं और पूछता हूं: "5 एमएस क्यों नहीं?" मैं यह कैसे पता लगा सकता हूं कि अनुरोध को संसाधित करने में क्या समय व्यतीत होता है? क्या इसे सिद्धांत रूप में त्वरित किया जा सकता है?

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

हमारे सर्वर में कौन से डिवाइस और कौन से संसाधन हैं, इसके बारे में तुच्छ तथ्यों पर विचार करें।



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

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

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

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

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



सबसे सरल बात संसाधनों का उपयोग, कुछ संख्यात्मक मूल्य पर देखना है। उदाहरण के लिए, आप कुछ शीर्ष शुरू करते हैं, और वह लिखते हैं: प्रोसेसर 100% है। या iostat चलाते हैं, और वह लिखते हैं: डिस्क 100% हैं। सच है, यह अक्सर पर्याप्त नहीं होता है। एक व्यक्ति यह देखेगा कि कार्यक्रम डिस्क पर टिकी हुई है। क्या किया जा सकता है? आप बस इसे नोट कर सकते हैं और आराम करने जा सकते हैं, यह तय कर सकते हैं कि सब कुछ, कुछ भी अनुकूलित नहीं किया जा सकता है। लेकिन वास्तव में, अपने आप में प्रत्येक डिवाइस काफी जटिल है। प्रोसेसर में विभिन्न प्रकार के संचालन के लिए कंप्यूटिंग उपकरणों का एक समूह है। डिस्क में RAID सरणी हो सकती है। यदि कोई एसएसडी है, तो उसके स्वयं के प्रोसेसर, अपने स्वयं के नियंत्रक के अंदर है, जो यह स्पष्ट नहीं करता है कि क्या है। और एक मान - 50% या 100% - पर्याप्त नहीं है। मूल नियम: यदि आप देखते हैं कि कुछ संसाधन 100% उपयोग किए जाते हैं, तो हार न मानें। अक्सर, आप अभी भी कुछ सुधार कर सकते हैं। लेकिन ऐसा होता है और इसके विपरीत। मान लीजिए कि आप देखते हैं कि रीसाइक्लिंग 50% है, लेकिन कुछ भी नहीं किया जा सकता है।

आइए इस पर करीब से नज़र डालते हैं।



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

अंत में, सिर्फ एक रेक होता है जब आपको लगता है कि आपका प्रोग्राम प्रोसेसर पर है। यह सच है, लेकिन किसी कारण से प्रोसेसर की आवृत्ति कम होती है। इसके कई कारण हो सकते हैं: अधिक गर्मी, बिजली की कमी। किसी कारण से, डेटा सेंटर में बिजली की कमी होती है, या ऊर्जा की बचत को बस चालू किया जा सकता है। फिर प्रोसेसर लगातार उच्च आवृत्ति से निम्नतर पर स्विच करेगा, लेकिन यदि आपका लोड अस्थिर है, तो यह पर्याप्त नहीं होगा और औसतन कोड अधिक धीरे-धीरे निष्पादित होगा। वर्तमान प्रोसेसर आवृत्ति के लिए टर्बोसैट देखें। Dmesg में overheating के लिए जाँच करें। अगर ऐसा कुछ हुआ है, तो यह कहेंगे: “ओवरहीटिंग। आवृत्ति नीचे। ”

यदि आप रुचि रखते हैं कि कितने कैश मिस के अंदर थे, तो प्रति चक्र कितने निर्देशों को निष्पादित किया जाता है, परफेक्ट रिकॉर्ड का उपयोग करें। कार्यक्रम का कुछ नमूना रिकॉर्ड करें। इसके अलावा परफैक्ट स्टेट या परफेक्ट रिपोर्ट का उपयोग करके इसे देखना संभव होगा।



और इसके विपरीत। मान लें कि आप शीर्ष पर देखते हैं और प्रोसेसर 50% से कम पुनर्नवीनीकरण है। मान लीजिए कि आपके सिस्टम में 32 वर्चुअल प्रोसेसर कोर और 16 भौतिक कोर हैं। इंटेल प्रोसेसर पर, ऐसा इसलिए है क्योंकि हाइपर-थ्रेडिंग डबल है। लेकिन इसका मतलब यह नहीं है कि अतिरिक्त कोर बेकार हैं। यह सब भार पर निर्भर करता है। मान लीजिए कि आपके पास कुछ अच्छी तरह से अनुकूलित रैखिक बीजगणित संचालन हैं या आपके पास खनन बिटकॉइन के लिए हैश है। फिर कोड स्पष्ट होगा, प्रति चक्र कई निर्देशों को निष्पादित किया जाएगा, कोई कैश मिस नहीं होगा, शाखा गलतफहमी भी होगी। और हाइपर-थ्रेडिंग मदद नहीं करता है। यह मदद करता है जब आपके पास एक कोर कुछ के लिए इंतजार कर रहा होता है, जबकि दूसरा एक साथ दूसरे धागे से निर्देशों को निष्पादित कर सकता है।

क्लिकहाउस में दोनों स्थितियां हैं। उदाहरण के लिए, जब हम डेटा एकत्रीकरण (ग्रुप बाय) करते हैं या सेट (इन सबक्वेरी) द्वारा फ़िल्टर करते हैं, तो हमारे पास एक हैश तालिका होगी। यदि हैश टेबल प्रोसेसर कैश में फिट नहीं होता है, तो कैश मिस हो जाएगा। इससे शायद ही बचा जा सके। इस मामले में, हाइपर-थ्रेडिंग हमारी मदद करेगी।

डिफ़ॉल्ट रूप से, ClickHouse हाइपर-थ्रेडिंग को छोड़कर केवल भौतिक प्रोसेसर कोर का उपयोग करता है। यदि आप जानते हैं कि आपका अनुरोध हाइपर-थ्रेडिंग से लाभान्वित हो सकता है, तो केवल थ्रेड्स की संख्या दोगुनी करें: SET अधिकतम थ्रेड = 32, और आपका अनुरोध अधिक तेज़ होगा।

ऐसा होता है कि प्रोसेसर पूरी तरह से उपयोग किया जाता है, लेकिन आप ग्राफ को देखें और देखें, उदाहरण के लिए, 10%। और आपका कार्यक्रम, उदाहरण के लिए, सबसे खराब स्थिति में पांच मिनट है। यहां तक ​​कि अगर यह एक-सेकंड है, तब भी कुछ प्रकार का औसत मूल्य है। वास्तव में, आपके पास लगातार अनुरोध थे, वे जल्दी से 100 सेकंड में निष्पादित होते हैं, प्रत्येक सेकंड में, और यह सामान्य है। क्योंकि ClickHouse अनुरोध को जितनी जल्दी हो सके निष्पादित करने का प्रयास करता है। वह पूरी तरह से पूरी तरह से और लगातार उपयोग करने और अपने प्रोसेसर को गर्म करने की कोशिश नहीं करता है।



आइए, थोड़ा जटिल विकल्प देखें। उपशम में एक अभिव्यक्ति के साथ एक क्वेरी है। उपकुंजी के अंदर, हमारे पास 100 मिलियन यादृच्छिक संख्याएं हैं। और हम सिर्फ इस परिणाम पर फ़िल्टर करते हैं।

ऐसी तस्वीर हम देखते हैं। वैसे, इस अद्भुत तस्वीर को मैं किस टूल से देखूंगा? बिल्कुल सच - पूर्ण। मुझे बहुत खुशी है कि आप यह जानते हैं।

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

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

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

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



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

हम खोलते हैं, उदाहरण के लिए, iostat, यह 100% का उपयोग दर्शाता है।

सम्मेलनों में, अक्सर ऐसा होता है कि स्पीकर मंच पर जाता है और पाथोस के साथ कहता है: “डेटाबेस हमेशा डिस्क को निरस्त करते हैं। इसलिए, हमने इन-मेमोरी डेटाबेस बनाया। वह धीमा नहीं होगा। ” यदि कोई व्यक्ति आपसे संपर्क करता है और ऐसा कहता है, तो आप उसे सुरक्षित रूप से भेज सकते हैं। कुछ समस्याएं होंगी - आप कहते हैं, मैंने इसे हल किया। :)

मान लीजिए कि एक कार्यक्रम डिस्क पर है, तो उपयोग 100 है। लेकिन इसका मतलब यह नहीं है कि हम डिस्क का उपयोग आशावादी तरीके से करते हैं।

एक विशिष्ट उदाहरण तब है जब आपके पास बहुत अधिक यादृच्छिक पहुंच है। यहां तक ​​कि अगर पहुंच अनुक्रमिक है, तो आप बस फ़ाइल को क्रमिक रूप से पढ़ते हैं, लेकिन यह अभी भी अधिक या कम इष्टतम हो सकता है।

उदाहरण के लिए, आपके पास एक RAID सरणी, कई उपकरण हैं - कहते हैं, 8 डिस्क। और आप बिना अनुक्रमिक रूप से पढ़े आगे पढ़े, 1 एमबी के बफर साइज़ के साथ, और RAID में आपके स्ट्राइप में चंक साइज़ भी 1 एमबी है। फिर प्रत्येक रीडिंग आपके पास एक डिवाइस से होगी। या, यदि दो उपकरणों से संरेखित नहीं किया गया है। आधा मेगाबाइट कहीं और जाएगा, एक और आधा मेगाबाइट कहीं, और इसी तरह - डिस्क का उपयोग बदले में किया जाएगा: एक, फिर दूसरा, फिर एक तीसरा।

इसे आगे पढ़ने की जरूरत है। या, यदि आपके पास O_DIRECT है, तो बफ़र का आकार बढ़ाएँ। यही है, नियम है: 8 डिस्क, चंक आकार 1 एमबी, बफर आकार को कम से कम 8 एमबी पर सेट करें। लेकिन यह केवल तभी काम करेगा जब रीडिंग संरेखित हो। और अगर संरेखित नहीं किया गया है, तो पहले अतिरिक्त टुकड़े होंगे, और आपको अधिक डालने की आवश्यकता है, कुछ और गुणा करें।

या, उदाहरण के लिए, आपके पास है RAID 10. आप किस गति से पढ़ सकते हैं RAID 10 - उदाहरण के लिए, 8 डिस्क से? क्या होगा फायदा? चौगुना, क्योंकि एक दर्पण है, या आठ गुना? वास्तव में, यह इस बात पर निर्भर करता है कि RAID कैसे बनाया जाता है, धारियों में किस प्रकार की व्यवस्था है।

यदि आप लिनक्स पर mdadm का उपयोग करते हैं, तो आप लेखन के लिए बेहतर होने, पढ़ने के लिए दूर होने के साथ, लेआउट और दूर के लेआउट को निर्दिष्ट कर सकते हैं।

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

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

एक और भयानक रेक है RAID 5 या RAID 6. सब कुछ वहाँ अनुक्रमिक पढ़ता है और लिखता है। RAID 5 में, बहुलता "उपकरणों की संख्या शून्य से एक है।" यह रैंडम रीडिंग के साथ भी अच्छा होता है, लेकिन यह रैंडम रीड्स के साथ अच्छा नहीं होता है। किसी भी एक स्थान पर रिकॉर्ड बनाएं, और आपको अन्य सभी डिस्क से डेटा पढ़ने की जरूरत है, उन्हें पोकसोरिट करें (एक्स - लगभग। एड।) और दूसरी जगह लिखें। इसके लिए, स्ट्रिप्स के एक निश्चित कैश का उपयोग किया जाता है, एक भयानक रेक। लिनक्स में, यह डिफ़ॉल्ट रूप से ऐसा है कि आप RAID 5 बनाते हैं और यह आपके लिए धीमा हो जाएगा। और आप सोचेंगे कि RAID 5 हमेशा धीमा हो जाता है, क्योंकि यह समझ में आता है। लेकिन वास्तव में, इसका कारण गलत सेटअप है।

एक और उदाहरण। आप एक एसएसडी से पढ़ रहे हैं, और आपने खुद को एक अच्छा एसएसडी खरीदा है, यह कहता है कि विनिर्देश में प्रति सेकंड 300 हजार यादृच्छिक पढ़ता है। और किसी कारण से आप ऐसा नहीं कर सकते और आप सोचते हैं - हाँ वे सभी अपने विनिर्देशों में झूठ बोलते हैं, ऐसी कोई बात नहीं है। लेकिन इन सभी रीडिंग को समानांतर में अधिकतम समानता के साथ किया जाना चाहिए। इसे पूरी तरह से करने का एकमात्र तरीका अतुल्यकालिक I / O का उपयोग करना है, जिसे सिस्टम कॉल io_submit, io_getevents, io_setup, आदि का उपयोग करके कार्यान्वित किया जाता है।

वैसे, डिस्क पर डेटा, यदि आप उन्हें संग्रहीत करते हैं, तो आपको हमेशा संपीड़ित करने की आवश्यकता होती है। मैं अभ्यास से एक उदाहरण दूंगा। एक व्यक्ति ने हमसे क्लिकहाउस समर्थन चैट में संपर्क किया और कहा:

- ClickHouse डेटा को कंप्रेस करता है। मैं देखता हूं कि यह प्रोसेसर पर टिकी हुई है। मेरे पास बहुत तेज NVMe SSDs हैं, उनके पास प्रति सेकंड कई गीगाबाइट की रीडिंग स्पीड है। क्या यह संभव है कि किसी तरह से ClickHouse में सम्पीडन को निष्क्रिय कर दिया जाए?
"नहीं, कोई रास्ता नहीं," मैं कहता हूँ। - आपको डेटा को संपीड़ित रखने की आवश्यकता है।
- इसे बंद कर दें, बस एक और संपीड़न एल्गोरिथ्म होने जा रहा है जो कुछ भी नहीं करता है।
- आराम से। इन अक्षरों को कोड की इस पंक्ति में दर्ज करें।
"वास्तव में, सब कुछ बहुत सरल है," उसने एक दिन बाद जवाब दिया। - मैंने किया।
- प्रदर्शन कितना बदल गया है?
"परीक्षण में असफल," उन्होंने एक दिन बाद लिखा। - बहुत अधिक डेटा है। वे अब SSDs पर फिट नहीं हैं।

आइए अब देखते हैं कि डिस्क से क्या पढ़ना पसंद कर सकते हैं। हम dstat शुरू करते हैं, यह पढ़ने की गति को दर्शाता है।


यहां पढ़ा गया कॉलम है - 300 एमबी / एस। हम डिस्क से पढ़ते हैं। यह बहुत या थोड़ा है - मुझे नहीं पता।

अब मैं इसे जांचने के लिए iostat चलाता हूं। यहां आप डिवाइस द्वारा ब्रेकडाउन देख सकते हैं। मेरे पास RAID, md2 और आठ हार्ड ड्राइव हैं। उनमें से प्रत्येक रीसाइक्लिंग दिखाता है, यह 100% (50-60%) तक भी नहीं पहुंचता है। लेकिन सबसे महत्वपूर्ण बात यह है कि मैं प्रत्येक डिस्क से केवल 20-30 एमबी / एस की गति से पढ़ता हूं। और बचपन से ही मुझे यह नियम याद था कि आप हार्ड ड्राइव से 100 एमबी / एस से कहीं पढ़ सकते हैं। किसी कारण से, यह अभी भी बहुत कुछ नहीं बदला है।


यहाँ एक और उदाहरण है। पढ़ना अधिक इष्टतम है। मैं dstat चलाता हूं, और मेरे पास इस RAID 5 को आठ ड्राइव में से 1 जीबी / एस की रीड स्पीड है। आईओस्टैट क्या दिखाता है? हां, लगभग 1 जीबी / एस।

अब ड्राइव अंत में 100% भरी हुई हैं। सच है, किसी कारण से, दो 100% हैं, और बाकी 95% हैं। शायद, वे अभी भी थोड़ा अलग हैं। लेकिन उनमें से प्रत्येक के साथ मैंने 150 एमबी / एस पढ़ा, यहां तक ​​कि कूलर भी हो सकता है। अंतर क्या है? पहले मामले में, मैं अपर्याप्त बफर के साथ अपर्याप्त टुकड़ों में पढ़ता हूं। यह सरल है, मैं आपको सामान्य सत्य बताता हूं।

वैसे, अगर आपको लगता है कि विश्लेषणात्मक डेटाबेस के लिए डेटा को अभी भी संपीड़ित करने की आवश्यकता नहीं है, अर्थात, हाईलोएड ++ साइबेरिया सम्मेलन ( रिपोर्ट के आधार पर habrastaty ) से एक रिपोर्ट - लगभग ।)। आयोजकों ने नोवोसिबिर्स्क में सबसे कट्टर रिपोर्ट बनाने का फैसला किया।



अगला उदाहरण स्मृति है। लगातार सामान्य सत्य। सबसे पहले, लिनक्स पर, कभी नहीं देखें कि क्या मुफ्त दिखाता है। जो लोग देख रहे हैं, उन्होंने विशेष रूप से साइट linuxatemyram.com बनाया है। अंदर आओ, एक स्पष्टीकरण होगा। आपको वर्चुअल मेमोरी की मात्रा को देखने की आवश्यकता नहीं है, क्योंकि क्या अंतर है, कार्यक्रम को कितना पता स्थान आवंटित किया गया है? भौतिक स्मृति का कितना उपयोग किया जाता है, इसे देखें।

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

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



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

या कल्पना करें - आप एक फ़ाइल स्थानांतरित कर रहे हैं, और आपके नेटवर्क पर एक बड़ी विलंबता और एक अच्छा पैकेट नुकसान है। तब यह बिल्कुल स्पष्ट नहीं है कि क्या फ़ाइलों को स्थानांतरित करने के लिए टीसीपी का उपयोग करना सही है। मुझे लगता है कि यह गलत है, क्योंकि टीसीपी निरंतरता की गारंटी देता है। दूसरी ओर, आप एक ही समय में फ़ाइल का आधा हिस्सा और दूसरे को स्थानांतरित कर सकते हैं। TCP- TCP . , , , TCP . .

100- , . 10 -, , , . . .



? — . , , , 10 . , .



: « - » — . iotop, , , iops.

, . .


top -, , clickHouse-server - , - . , , Shift+H, . , ClickHouse . ParalInputsProc, . BackgrProcPool — merges . , .

? ClickHouse, , . BackgroundProcessingPool. 15 . 16 1, 1 — . 16? , Linux — , : «16 . ». :)

clickhouse-benchmark. clickhouse-client. , clickhouse-client, . - . .


. clickhouse-benchmark, , , , , . peft top. peft top, . , - -, uniq: UniquesHashSet. . , . , .

, , . — -. , , XOR - . -. - -. , -.

, , crc32q. , , - , - .

, ClickHouse. , , . ClickHouse.



. , — , SHOW PROCESSLIST. . , SELECT * FROM system processes. : , , . ClickHouse top.

ClickHouse ? background-. Background- — merges. , merges , SELECT * FROM system.merges.


, . -. . — ClickHouse. . , , . , . - traf_testing. ? , , . ClickHouse .



. , . , , , , . query_log. — , - , SELECT , - . query_log , . - . — , . : .

, , — merge, inserts, . part_log. , .



query_log clickhouse-benchmark. select , , stdin clickhouse-benchmark.

query_log - , .



, , . . SET send_logs_level = 'trace', , .


, . , 98%. , . यह बहुत सरल है। SET send_logs_level = 'trace', , . - : merging aggregated data, . 1% . , .

, , query_log.

. SELECT * FROM system.query_log . . , , , query_log. . — , , , . .



ClickHouse . — system.events, system.metrics system.asynchronous_metrics. Events — , , . 100 . — 10 . system.metrics — . , 10 , 10 .

system.asynchronous_metrics , . . — . , system.asynchronous_metrics — , - . , .

, . SHOW PROCESSLIST . query_log, .



, . , . , . , , . , Linux, . Linux . , . , . .

, OSReadChars OSReadBytes. ? , , , . , . , , , . , - , .


, . - . , 40 , 6,7 . . , , . , , .

, 1,3 , 5 . क्यों? , — page cache. ?


. . , , . . : 3,2 , — 2,5 . , , , . क्यों? -, : read ahead. , — ? -, — 4 , , 512 KB. . , . , - read ahead.



. . , . , , ReadBytes — , . 3 , 3 . , , .

— IOWait. 87 . 7 , IOWait — 87. ? — . . , , 87 . , - .

— CPUWait. , , , . - — , . CPU. CPU. - , . — , , user space. , - . अच्छा, ठीक है।

— , Linux. - , . , , .


और अब हमारे पास सबसे उन्नत चीज़ है: query_thread_log। इसके साथ, आप समझ सकते हैं कि क्वेरी निष्पादन के प्रत्येक धागे ने किस समय बर्बाद किया।

मैं अपने अनुरोध की तलाश करता हूं, query_id द्वारा चयन करता हूं और मीट्रिक "उपयोगकर्ता स्थान में बिताए गए प्रोसेसर समय की मात्रा" इंगित करता हूं। यहाँ हमारी धाराएँ हैं। अनुरोध के समानांतर प्रसंस्करण के लिए, 16 धागे आवंटित किए गए थे। उनमें से प्रत्येक ने 800 एमएस खर्च किए। और फिर कुल कार्यों के राज्य के विलय के लिए एक और 16 धागे आवंटित किए गए थे, उनमें से प्रत्येक पर 0.25 एस खर्च किए गए थे। अब मैं समझ सकता हूं कि प्रत्येक अनुरोध में क्या समय लगा।

HighLoad ++ पर वीडियो रिपोर्ट: