जब अधिकतम प्रदर्शन के लिए सिस्टम को अनुकूलित करने की बात आती है, तो गलतियों को करना बहुत आसान हो सकता है यदि आप लापरवाही से अन्य लोगों के प्रथाओं को लागू करते हैं। ऐसी ही एक प्रथा है फाइल सिस्टम को बढ़ते समय नोबैरियर को निर्दिष्ट करना।
इस नोट का जन्म कैसे हुआ
मैं Mail.Ru क्लाउड सॉल्यूशंस में एक इंजीनियर के रूप में काम करता हूं और मुख्य रूप से "आसपास और आसपास" सभी प्रकार के ब्लॉक स्टोरेज से निपटता हूं, जिस पर हमारे उपयोगकर्ताओं की वर्चुअल मशीनें झूठ बोलती हैं - और, तदनुसार, आभासी मशीनों के प्रदर्शन और स्थिरता से संबंधित दिलचस्प मामले अक्सर सामने आते हैं। अनुप्रयोग - और विशेष रूप से डेटाबेस।
एक नियम के रूप में, "डीब्रीफिंग" के दौरान लगभग आधे मामलों में हम एक ही चीज देखते हैं - एक फाइल सिस्टम जो कि नॉबरियर विकल्प के साथ मुहिम की जाती है। और जब हम पूछते हैं - "आपने यह विकल्प क्यों लिखा है", तो हमें लगभग हमेशा उत्तर विकल्पों में से एक मिलता है "मुझे बताया गया था कि यह तेज था / मैंने पढ़ा था कि यह तेज था / मुझे इस तरह सेट किया गया था" - जिसके बाद हम विनम्रता से और सावधानी से समझाने की कोशिश करते हैं एसओ को जरूरत नहीं है। क्यों? क्योंकि डेटा हानि के लिए सड़क पर यह पहला आश्वस्त कदम है।
लघु भ्रमण
फ़ाइल सिस्टम - संरचना बहुत जटिल और अत्यधिक भरी हुई है। अधिकतम प्रदर्शन सुनिश्चित करने के लिए, कैशिंग और समानांतर रिकॉर्डिंग सक्रिय रूप से प्रक्रिया में उपयोग की जाती है। तदनुसार, डेटा का कुछ हिस्सा कैश में चला जाता है और जब भी संभव हो, तब या "मांग पर" खारिज कर दिया जाता है। एक बाधा एक विशेष ऑपरेशन है जो सभी कैश को डिस्क में फ्लश करने के लिए मजबूर करता है।
जब यह डेटाबेस की बात आती है, तो हमें यह सुनिश्चित करना चाहिए कि ग्राहक (क्लाइंट एप्लिकेशन) को पुष्टि की गई लेन-देन लगातार बनी रही है और एक तरफ गायब नहीं होगी, और दूसरी तरफ, डीबीएमएस सक्रिय रूप से अधिकतम प्रदर्शन प्राप्त करने के लिए और निरंतरता सुनिश्चित करने के लिए अपने स्वयं के कैशिंग का उपयोग करते हैं। जर्नलिंग का उपयोग किया जाता है - परिवर्तन लॉग में लिखा जाता है, लॉग "सिंक" हो जाता है और फिर परिवर्तन डेटा को लिखा जाता है (और जब यह लिखा जाता है, तो यह कैश में हो जाता है)। जब लॉग भरा होता है, तो कैश में सभी डेटा के लिए एक मजबूर सिंक किया जाता है और लॉग फिर से पॉप्युलेट होने लगता है।
सिंक ऑपरेशन
जब सिंक निष्पादित होता है, तो ऑपरेटिंग सिस्टम न केवल पेज कैश को फ्लश करता है, लेकिन डिफ़ॉल्ट रूप से सभी डिस्क कैश फ्लश करने के लिए एक कमांड भेजता है (और, संभवतः, यह बार-बार करता है) - तथाकथित
बह जाना । बफ़र्स फ्लशिंग का संचालन "महंगा" है और इसमें काफी समय लगता है - लेकिन यह आवश्यक है, क्योंकि फ़ाइल सिस्टम में लेखन का क्रम महत्वपूर्ण है - यदि इसका उल्लंघन किया जाता है, तो (उदाहरण के लिए) यह पता चल सकता है कि जब अचानक रिबूट होता है, तो फ़ाइल में डेटा के बजाय कचरा होगा - डिवाइस के बाद से रिकॉर्ड को फिर से व्यवस्थित करने का फैसला किया। और जब फ्लश जबरन सभी कैश फ्लश करता है - यह सुनिश्चित करता है कि पहले फ्लश लिखा हुआ है उससे पहले, और उसके बाद ही क्या हुआ - यानी, "बाधा" और "बाधा के बाद" से प्रविष्टियों को विभाजित करने के लिए एक "बैरियर" बनाया गया है (यहां से) और नाम "बैरियर राइट") - और इससे यह गारंटी देना संभव हो जाता है कि बैरियर के बाद के रिकॉर्ड बैरियर से पहले के रिकॉर्ड से पहले लागू नहीं होंगे।
नोबैरियर प्रभाव
फाइल सिस्टम के चलने के दौरान नॉबरियर विकल्प जबरन फ्लश भेजने में अक्षम कर देता है। यह इस तथ्य की ओर जाता है कि रिकॉर्ड को फिर से व्यवस्थित किया जा सकता है - और यदि कोई विफलता होती है, तो फ़ाइल सिस्टम (और आमतौर पर सामान्य मामले में डेटा) सुसंगत नहीं हो सकता है - चलो याद करते हैं कि रिकॉर्डिंग क्रम के बारे में पिछले पैराग्राफ में क्या उल्लेख किया गया था।
यह विकल्प क्यों शामिल है? कम लागत वाली एसएसडी के लिए, फ्लश ऑपरेशन बहुत महंगा है - उदाहरण के लिए, कम लागत वाली एसएसडी (और कई महंगी जो "सर्वर" के रूप में तैनात हैं) प्रति फ्लश के बिना प्रति सेकंड 10-20 हजार लेखन कार्य करती हैं, और फ्लश के साथ, वे 1-2 हजार तक गिरते हैं। ऐसे मामलों में, nobarrier एक महत्वपूर्ण प्रदर्शन को बढ़ावा देता है, जो ऊपर वर्णित डेटा अखंडता के लिए जोखिम पैदा करता है।
आभासी वातावरण
एक वर्चुअल मशीन के मामले में - यदि, उदाहरण के लिए, हम लिनक्स हाइपरविजर पर वर्चुअल मशीनों के शास्त्रीय विन्यास के बारे में बात कर रहे हैं, तो हमारे पास QEMU है - एक प्रक्रिया जो वास्तव में अतिथि ऑपरेटिंग सिस्टम के लिए I / O का अनुकरण करने के लिए जिम्मेदार है। और सबसे महत्वपूर्ण बात, अगर हम वर्चुअल मशीन में नॉन-फाइल-समर्थित डिस्क का उपयोग करते हैं, तो ऐसी वर्चुअल डिस्क का कैश (अचानक?) उपयोगकर्ता स्पेस में - संबंधित QEMU प्रक्रिया के एड्रेस स्पेस में होता है। और अगर यह प्रक्रिया क्रैश हो जाती है - उदाहरण के लिए, SEGFAULT / SIGSEGV के अनुसार - तो इसके सभी कैश इसके साथ मर जाएंगे। इस तरह के एक ब्लॉक डिवाइस ड्राइवर का एक उदाहरण RBD (सेफ) ड्राइवर है।
और भले ही आप सिफ का उपयोग न करें लेकिन iSCSI / FC, उदाहरण के लिए, विफलता स्तर गायब नहीं होता है - यह केवल QEMU से होस्ट ऑपरेटिंग सिस्टम (हाइपरविजर) में बदल जाता है। हाइपरविजर गिर गया - इसके पृष्ठ कैश की मृत्यु हो गई (यह io = 'थ्रेड्स के लिए कैश =' राइटबैक 'या कैश =' असुरक्षित 'के संयोजन में सत्य है)। उफ़।
एस / क्लाउड / एलियन कंप्यूटर / जी
जब आपकी वर्चुअल मशीन क्लाउड में तैनात होती है ... तो आप नहीं जानते कि हाइपरवाइजर कैसे कॉन्फ़िगर किया गया है, QEMU कैसे कॉन्फ़िगर किया गया है, डिस्क ड्रायवर क्या शामिल हैं, क्या होस्ट का पेज कैश काम करता है, आदि, और आप इसे अधिकांश मामलों में प्रभावित नहीं कर सकते। और यहां तक कि अगर यह आपका क्लाउड है - जहां आप यह सब जानते हैं और कम या ज्यादा इसे नियंत्रित करते हैं, तो यह बिल्कुल भी नहीं है कि आपका हाइपरवाइजर पूरे डेटा कैश को "गिर" नहीं करेगा।
सारांश
क्लाउड में नोबैरियर का उपयोग करने का मतलब है कि आप अपने डेटा को जोखिम में डाल सकते हैं। क्या आप वाकई इन जोखिमों की कीमत पर उत्पादकता हासिल करना चाहते हैं?