क्या हमें ext3 पर डेटा = राइटबैक और बैरियर = 0 के साथ माउंट करना चाहिए?


13

हम एक होस्टिंग कंपनी में एक वीएम पर एक सर्वर चला रहे हैं, और अभी एक समर्पित होस्ट (एएमडी ओपर्टन 3250, 4 कोर, 8 जीबी रैम, सॉफ्टवेयर एक्स, एक्स 3 में 2 एक्स 1 टीबी) के लिए साइन अप किया है।

प्रदर्शन परीक्षण चलाते समय, हमने देखा कि कुछ SQLite बदलाव (आवेषण, डिलीट और / या अपडेट का संयोजन) मेरे 2010 मैकबुक प्रो की तुलना में 10x से 15x लंबे समय तक ले रहे थे।

बहुत सारे गुग्लिंग और पढ़ने के बाद, हमने माउंट विकल्पों पर गौर किया, जो थे:

    data=ordered,barrier=1

हमने कुछ प्रयोग किए हैं, और सबसे अच्छा प्रदर्शन किया है

    data=writeback,barrier=0

मैंने इन पर पढ़ा है, और जो वे कर रहे हैं, उसके मूल को समझते हैं, लेकिन मेरे पास इस तरह से चलाने के लिए एक अच्छा विचार / अनुभव नहीं है कि क्या यह हमारे लिए एक अच्छा विचार है?

प्रशन

क्या होस्टेड सेवा के लिए विचार करने के लिए उपरोक्त विन्यास भी समझदार है?

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

क्या अन्य विकल्प हैं जिन पर हमें विचार करना चाहिए?

धन्यवाद


कई कारक शामिल हैं। क्या आप कई कठिन दुर्घटनाओं की उम्मीद करते हैं? क्या आपके पास एक होस्ट (या कुछ समतुल्य) आपकी होस्टेड मशीन से जुड़ा है? क्या आपने अन्य फ़ाइल सिस्टम (जैसे ext4, XFS, आदि) के साथ कुछ बेंचमार्किंग की? क्या आप एचडीडी कैश को नियंत्रित ((डी) सक्रिय कर सकते हैं)? आपने अपने सॉफ़्टवेयर को कैसे कॉन्फ़िगर किया RAID? क्या आप एचडीडी ठीक से संरेखित हैं (यदि 4K ब्लॉक हैं)?
ह्यूजेंस

हम कई कठिन दुर्घटनाओं की उम्मीद नहीं करते हैं। हमारे पास यूपीएस नहीं है। मशीन कल्पना होस्टिंग कंपनी से एक मानक "शेल्फ से दूर" थी, इसलिए: हमने अन्य एफएस को बेंचमार्क नहीं किया, एक्स 3 वह है जो हमें मिला है। HDD कैश पर पता नहीं है, उस पर गौर करेंगे, और इसी तरह RAID और HDD संरेखण के लिए। धन्यवाद।
नील

एक और सवाल मैं भूल गया कि आप कितना इतिहास गंवा सकते हैं? या आप किसी भी खो बर्दाश्त नहीं कर सकता? नोट: SQLite स्नैपशॉट का समर्थन करता है, या दूसरे शब्दों में एक रनिंग डेटाबेस का समर्थन करता है। sqlite.org/backup.html
Huygens

आपका कर्नेल संस्करण क्या है? बाधाओं को md द्वारा 2.6.33 के बाद से सम्मानित किया जाता है, पिछले कर्नेल रिलीज़ में नहीं।
Huygens

uname -r रिपोर्ट "2.6.32-220.2.1.el6.x86_64"। "Md" क्या है? यदि कर्नेल के इस संस्करण में बाधाओं का सम्मान नहीं किया जाता है, तो बाधाओं को बंद करने पर मुझे प्रदर्शन में सुधार क्यों दिखाई दिया?
नील

जवाबों:


15

पहली सलाह
यदि आप कोई डेटा नहीं खो सकते हैं (मेरा मतलब है कि एक बार जब कोई उपयोगकर्ता नए डेटा में प्रवेश करता है, यदि वह आने वाले सेकंड में खो नहीं सकता है) और क्योंकि आपके पास यूपीएस जैसा कुछ नहीं है, तो मैं लिखने की बाधा को नहीं हटाऊंगा, न तो मैं राइटबैक पर जाऊंगा।

लेखन अवरोधों को
हटाना यदि आप लेखन अवरोध को हटाते हैं, तो दुर्घटना या बिजली की हानि के मामले में, फ़ाइल सिस्टम को डिस्क संरचना को सुधारने के लिए एक fsck करना होगा (ध्यान दें कि यहां तक ​​कि बाधा पर भी, अधिकांश जर्नलिंग फ़ाइल सिस्टम अभी भी fsck करेगा हालांकि, जर्नल की रीप्ले पर्याप्त होना चाहिए)। राइट बैरियर हटाते समय, यदि संभव हो तो किसी भी डिस्क कैशिंग (हार्डवेयर पर) को हटाने की सलाह दी जाती है, इससे जोखिम को कम करने में मदद मिलती है। आपको हालांकि इस तरह के बदलाव के प्रभाव को मापना चाहिए। आप इस कमांड को आज़मा सकते हैं (यदि आपका हार्डवेयर इसका समर्थन करता है) hdparm -W0 /dev/<your HDD>
ध्यान दें कि ext3 मेटाडेटा परिवर्तन के लिए 2 बाधाओं का उपयोग करता है, जबकि ext4 माउंट विकल्प का उपयोग करते समय केवल एक का उपयोग करता है journal_async_commit

हालांकि टेड टीओ ने बताया कि एक्स 3 के शुरुआती दिनों में कुछ डेटा भ्रष्टाचार क्यों हुआ ( कर्नेल 3.1 तक डिफ़ॉल्ट रूप से अवरोध थे ), जर्नल को इस तरह से रखा गया है कि जब तक कोई जर्नल लॉग रैप नहीं होता है (जर्नल एक चक्रीय लॉग है) डेटा को एक सुरक्षित क्रम में डिस्क पर लिखा जाता है - जर्नल पहले, डेटा दूसरा - यहां तक ​​कि हार्ड डिस्क के साथ लिखने का पुन: व्यवस्थित करने का समर्थन करता है।
मूल रूप से, यह अशुभ होगा कि सिस्टम लॉग या पावर लॉस तब होता है जब जर्नल लॉग रैप होता है। हालांकि, आपको रखने की आवश्यकता है data=ordereddata=ordered,barrier=0इसके अलावा बेंचमार्क करने की कोशिश करें ।

यदि आप कुछ सेकंड का डेटा खो सकते हैं, तो आप दोनों विकल्पों को सक्रिय कर सकते हैं, data=writeback,barrier=0लेकिन फिर commit=<nrsec>पैरामीटर के साथ भी प्रयोग करने का प्रयास कर सकते हैं । इस पैरामीटर के लिए मैनुअल यहां देखें । मूल रूप से आप कई सेकंड देते हैं जो एक अवधि है एक्स 3 फ़ाइल सिस्टम इसके डेटा और मेटाडेटा को सिंक करेगा।
आप गंदे पन्नों (जिन्हें डिस्क पर लिखने की आवश्यकता है) के बारे में कुछ कर्नेल ट्यूबल्स के साथ बेला और बेंचमार्क करने की कोशिश कर सकते हैं, यहां एक अच्छा लेख है जो इन सुरंगों के बारे में सब कुछ बताता है और उनके साथ कैसे खेलना है।

बाधाओं के बारे में सारांश
आपको कुछ और संयोजनों के बारे में जानना चाहिए:

  1. data=writeback,barrier=0के साथ संयोजन के रूप में उपयोग करेंhdparm -W0 /dev/<your HDD>
  2. उपयोग data=ordered,barrier=0
  3. data=writeback,barrier=0अन्य माउंट विकल्प के साथ संयोजन में उपयोग करें commit=<nrsec>और nrsec के लिए अलग-अलग मान आज़माएं
  4. विकल्प 3 का उपयोग करें। और गंदे पन्नों के बारे में कर्नेल स्तर पर आगे भी पढ़ने योग्य है।
  5. सुरक्षित का उपयोग करें data=ordered,barrier=1, लेकिन अन्य ट्यूनबल्स आज़माएं : विशेष रूप से फाइलसिस्टम एलेवेटर (सीएफक्यू, डेडलाइन या नूप) और उनके रेस्पेक्टेबल ट्यूनबल्स।

Ext4 के लिए आगे बढ़ना और इसे बेंचमार्किंग मानते हुए
कहा कि ext4 को लिखने के लिए ext3 से कम अवरोध की आवश्यकता होती है। इसके अलावा, ext4 एक्स्टेंट का समर्थन करता है जो बड़ी फ़ाइलों के लिए बेहतर प्रदर्शन ला सकता है। तो यह खोज के लायक एक समाधान है, खासकर जब से यह एक3 से पलायन करने के लिए ext4 से बाहर निकलना आसान है पुनर्स्थापित किए बिना: आधिकारिक दस्तावेज ; मैंने ऐसा एक सिस्टम पर किया लेकिन इस डेबियन गाइड का उपयोग किया । Ext4 वास्तव में कर्नेल 2.6.32 के बाद से स्थिर है, इसलिए उत्पादन में उपयोग करना सुरक्षित है।

अंतिम विचार
यह उत्तर पूर्ण से दूर है, लेकिन यह आपको जांच शुरू करने के लिए पर्याप्त सामग्री देता है। यह आवश्यकताओं (उपयोगकर्ता या सिस्टम स्तर पर) पर इतना अधिक निर्भर है कि इसके बारे में सीधा जवाब देना कठिन है, इसके बारे में खेद है।


धन्यवाद - वहाँ बहुत सारे उपयोगी सामान। मैंने पहले ही ext3 doc को kern.org पर पढ़ा था, और कमिट करने की कोशिश की, लेकिन जो बड़ी कीमत थी उसके लिए कोई मतलब नहीं था। 5 सेकंड के बजाय 15 पर सेट करें मैंने कोई बदलाव नहीं देखा। आपके द्वारा सुझाए गए क्रमपरिवर्तन को कवर करने के लिए, मैं कुछ और बेंचमार्किंग करूँगा। एक बार फिर धन्यवाद।
नील

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

1.: @NeilB सिर्फ इन लेखों पर ठोकर sqlite.org/draft/lockingv3.html के लिए देखो ext3उस में। यह समझने में आसान (या सरलीकृत) स्पष्टीकरण देता है जो मैंने अपने उत्तर में संबोधित करने की कोशिश की थी। 2. sqlite.1065341.n5.nabble.com/ ... आप सुरक्षित ext3 चूक (आदेशित + बाधा) को रखने की कोशिश कर सकते हैं, लेकिन SQLite में सिंक को हटा सकते हैं। मैं इस दूसरे पहलू के बारे में अपना जवाब जल्द ही अपडेट करूंगा।
Huygens

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

10

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

वहाँ कई परतें हैं जहाँ आप SQLite लेखन प्रदर्शन के बारे में चिंता कर सकते हैं:

प्रदर्शन के बारे में सोचने के लिए विभिन्न स्तर

हमने बोल्ड में हाइलाइट किए गए लोगों को देखा। विशेष पैरामीटर थे

  • डिस्क कैश लिखें। आधुनिक डिस्क में रैम कैश होता है जिसका उपयोग डिस्क लिखने को कताई डिस्क के संबंध में करने के लिए किया जाता है। इस सक्षम के साथ, डेटा को आउट-ऑफ-ऑर्डर ब्लॉकों में लिखा जा सकता है, इसलिए यदि कोई दुर्घटना होती है, तो आप आंशिक रूप से लिखित फ़ाइल के साथ समाप्त हो सकते हैं। HDparm -W / dev / ... के साथ सेटिंग की जाँच करें और इसे hdparm -W1 / dev / ... (इसे चालू करने के लिए, और -W0 इसे बंद करने के लिए) के साथ सेट करें।
  • बाधा = (0 | 1)। ऑनलाइन टिप्पणियों के बहुत सारे "अगर आप बाधा = 0 के साथ चलते हैं, तो डिस्क लेखन कैशिंग सक्षम नहीं है"। आप http://lwn.net/Articles/283161/ पर बाधाओं की चर्चा पा सकते हैं
  • डेटा = (पत्रिका | आदेश दिया | राइटबैक)। को देखो http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html इन विकल्पों के वर्णन के लिए।
  • प्रतिबद्ध = एन। सभी डेटा और मेटाडेटा को हर N सेकंड (डिफ़ॉल्ट 5) को सिंक करने के लिए ext3 बताता है।
  • SQLite pragma तुल्यकालिक = ON | बंद। जब चालू होता है, तो SQLite सुनिश्चित करेगा कि जारी रखने से पहले एक लेनदेन "डिस्क पर लिखा गया है"। अनिवार्य रूप से इसे बंद करने से अन्य सेटिंग्स काफी हद तक अप्रासंगिक हो जाती हैं।
  • SQLite pragma cache_size। नियंत्रण करता है कि स्मृति इन-कैश के लिए SQLite कितना मेमोरी का उपयोग करेगा। मैंने दो आकारों की कोशिश की: एक जहां पूरा DB कैश में फिट होगा, और एक जहां कैश अधिकतम DB आकार का आधा था।

Ext3 प्रलेखन में ext3 विकल्पों के बारे में अधिक पढ़ें ।

मैंने इन मापदंडों के कई संयोजनों पर प्रदर्शन परीक्षण चलाए। आईडी एक परिदृश्य संख्या है, जिसे नीचे संदर्भित किया गया है।

परिदृश्य मैंने कोशिश की

मैंने अपनी मशीन पर डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ परिदृश्य 1 के रूप में चलना शुरू कर दिया। परिदृश्य 2 वह है जिसे मैं "सबसे सुरक्षित" मानता हूं, और फिर विभिन्न संयोजनों की कोशिश की, जहां उपयुक्त / संकेत दिया गया। यह संभवतः मेरे द्वारा उपयोग किए गए मानचित्र के साथ समझने में आसान है:

मापदंडों से संबंधित परिदृश्यों का नक्शा

मैंने एक टेस्ट स्क्रिप्ट लिखी, जिसमें बहुत सारे लेन-देन, आवेषण, अपडेट और डिलीट के साथ, सभी टेबल पर केवल INTEGER के साथ, केवल TEXT (आईडी कॉलम के साथ), या मिश्रित मिला। मैंने ऊपर के प्रत्येक विन्यास पर इसे कई बार चलाया:

परिदृश्यों के लिए समय दिखा भूखंड

नीचे के दो परिदृश्य # 6 और # 17 हैं, जिनमें "प्राग समकालिक = बंद" है, इसलिए यह आश्चर्यजनक है कि वे सबसे तेज़ थे। तीन के अगले क्लस्टर # 7, # 11 और # 19 हैं। इन तीनों को "कॉन्फ़िगरेशन मानचित्र" पर नीले रंग में हाइलाइट किया गया है। मूल रूप से कॉन्फ़िगरेशन डिस्क लेखन कैश ऑन, बैरियर = 0, और डेटा 'जर्नल' के अलावा किसी अन्य चीज़ के लिए सेट है। 5 सेकंड (# 7) और 60 सेकंड (# 11) के बीच परिवर्तन करने से कुछ फर्क नहीं पड़ता। इन परीक्षणों पर डेटा = ऑर्डर किया गया और डेटा = राइटबैक के बीच कोई अंतर नहीं है, जो मुझे आश्चर्यचकित करता है।

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

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

मिश्रित प्रकार और सम्मिलित / अद्यतन / हटाएं

यहां आप देख सकते हैं कि राइटबैक कॉन्फ़िगरेशन (# 19) ऑर्डर किए गए लोगों की तुलना में थोड़ा धीमा है (# 7 और # 11)। मुझे उम्मीद थी कि राइटबैक थोड़ा तेज़ होगा, लेकिन शायद यह आपके लेखन पैटर्न पर निर्भर करता है, या शायद मैंने अभी तक एक्स 3 पर पर्याप्त पढ़ा नहीं है :-)

विभिन्न परिदृश्य हमारे अनुप्रयोग द्वारा किए गए संचालन के कुछ प्रतिनिधि थे। परिदृश्यों की एक शॉर्टलिस्ट चुनने के बाद हमने अपने कुछ स्वचालित परीक्षण सूटों के साथ समय परीक्षण किया। वे ऊपर के परिणामों के अनुरूप थे।

निष्कर्ष

  • प्रतिबद्ध पैरामीटर, थोड़ा अंतर बनाने के लिए लग रहा था तो हम 5s पर जा रहे हैं।
  • हम डिस्क पर कैश लिखने जा रहे हैं, बाधा = 0 , और डेटा = ऑर्डर किया गया । मैंने कुछ चीजें ऑनलाइन पढ़ीं जो सोचा कि यह एक बुरा सेटअप है, और अन्य जो यह सोचते हैं कि यह बहुत सारी स्थितियों में डिफ़ॉल्ट होना चाहिए। मुझे लगता है कि सबसे महत्वपूर्ण यह है कि आप एक सूचित निर्णय लेते हैं, यह जानते हुए कि आप क्या व्यापार बंद कर रहे हैं।
  • हम SQLite में सिंक्रोनस प्राग्म का उपयोग करने नहीं जा रहे हैं।
  • SQLite cache_size pragma की स्थापना इसलिए DB कुछ मेमोरी पर बेहतर प्रदर्शन में फिट होगा, जैसा कि हम उम्मीद करते हैं।
  • उपरोक्त कॉन्फ़िगरेशन का मतलब है कि हम थोड़ा अधिक जोखिम ले रहे हैं। हम आंशिक लिखने पर डिस्क विफलता के खतरे को कम करने के लिए SQLite बैकअप एपीआई का उपयोग करेंगे : प्रत्येक एन मिनट पर एक स्नैपशॉट लेना और अंतिम एम को इधर-उधर रखना। मैंने प्रदर्शन परीक्षण चलाते समय इस एपीआई का परीक्षण किया, और इसने हमें इस तरह जाने के लिए आत्मविश्वास दिया है।
  • यदि हम अभी भी अधिक चाहते थे, तो हम कर्नेल के बारे में मिलाना देख सकते हैं, लेकिन हमने वहां जाने के बिना चीजों को बेहतर बनाया।

विभिन्न युक्तियों और संकेत के लिए @Huygens को धन्यवाद।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.