फ़ाइल सिस्टम का उपयोग करके बैकअप गति का अनुकूलन (आगे पढ़ें, आगे पढ़ें)

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

VxFS फ़ाइल सिस्टम (Symantec) के लिए उदाहरण दिए गए हैं। यह फाइल सिस्टम व्यापक रूप से सर्वर सिस्टम में उपयोग किया जाता है और HP-UX, AIX, Linux, Solaris पर समर्थित है।

इसकी आवश्यकता क्यों है?

सवाल यह है कि किसी स्ट्रीम में डेटा को क्रमिक रूप से पढ़ने पर अधिकतम गति कैसे प्राप्त करें (!) इस फाइल के दायरे से परे एक बड़ी फाइल (बड़ी संख्या में छोटी फाइलों का बैकअप) से। अनुक्रमिक रीडिंग द्वारा, हम इस पर विचार करते हैं जब भौतिक डिस्क से डेटा के ब्लॉक एक के बाद एक क्रम में अनुरोध किए जाते हैं। हम मानते हैं कि फ़ाइल सिस्टम विखंडन अनुपस्थित है। यह उचित है, क्योंकि अगर फ़ाइल सिस्टम पर कुछ बड़ी फाइलें हैं और उन्हें शायद ही कभी फिर से बनाया जाता है, तो वे व्यावहारिक रूप से खंडित नहीं होते हैं। यह Oracle जैसे डेटाबेस के लिए एक सामान्य स्थिति है। इस मामले में एक फ़ाइल से पढ़ना एक कच्चे डिवाइस से पढ़ने से बहुत अलग नहीं है।

एकल-थ्रेडेड पढ़ने की सीमा क्या है?

सबसे तेज़ आधुनिक ड्राइव (15K rpm) का सेवा समय लगभग 5.5 ms (सिद्धांत पाठकों की कतार के लिए है, हम प्रतीक्षा समय को 0 मानते हैं)।
हम इनपुट-आउटपुट संचालन की संख्या को परिभाषित करते हैं जो एक प्रक्रिया (बैकअप) कर सकती है:

1 / 0.0055 = 182 IO प्रति सेकंड (iops)।

यदि कोई प्रक्रिया क्रमिक रूप से संचालन करती है, जिसमें से प्रत्येक 5.5 एमएस तक चलता है, तो यह प्रति सेकंड 182 टुकड़ों को निष्पादित करेगा। मान लीजिए कि ब्लॉक का आकार 256KB है। इस प्रकार, इस प्रक्रिया का अधिकतम थ्रूपुट होगा: 182 * 256 = 46545 KB / s। (46 एमबी / एस)। विनय, ठीक है? यह विशेष रूप से सैकड़ों भौतिक स्पिन्डल्स वाले सिस्टम के लिए मामूली है जब हम बहुत तेज पढ़ने की गति पर भरोसा करते हैं। सवाल यह है कि इसे कैसे अनुकूलित किया जाए। डिस्क तक पहुंच के समय को कम करना असंभव है, क्योंकि ये तकनीकी सीमाएं हैं। समानांतर बैकअप भी हमेशा संभव नहीं होता है। इस सीमा को हटाने के लिए, फ़ाइल सिस्टम एक रीड फॉरवर्ड मैकेनिज्म लागू करता है।

कैसे काम करता है आगे पढ़ें

आधुनिक * निक्स सिस्टम में, I / O अनुरोध दो प्रकार के होते हैं: सिंक्रोनस और एसिंक्रोनस। एक सिंक्रोनस अनुरोध के साथ, डिस्क सबसिस्टम से प्रतिक्रिया प्राप्त होने तक प्रक्रिया अवरुद्ध है। जब एसिंक्रोनस, यह ब्लॉक नहीं करता है और कुछ भी कर सकता है। अनुक्रमिक पढ़ने में, हम डेटा को सिंक्रोनाइज़ करते हैं। जब रीड-फॉरवर्ड मैकेनिज्म चालू होता है, तो फाइल सिस्टम कोड, सिंक्रोनस रिक्वेस्ट के तुरंत बाद, कई और एसिंक्रोनस बनाता है। मान लें कि अनुरोध की गई प्रक्रिया ब्लॉक नंबर 1000 है। जब आगे पढ़ा जाता है तो ब्लॉक 1000 के अलावा, 1001,1002,1003,1004 भी अनुरोध किया जाएगा। इस प्रकार, ब्लॉक 1001 का अनुरोध करते समय, हमें 5.5 एमएस प्रतीक्षा करने की आवश्यकता नहीं है। आगे की सेटिंग का उपयोग करके, आप अनुक्रमिक रीड की गति को बढ़ा सकते हैं।

इसे कैसे कॉन्फ़िगर किया गया है?

एक प्रमुख रीड-फॉरवर्ड सेटिंग इसका आकार है। आगे देखते हुए, मैं कहूंगा कि आगे पढ़ने के साथ दो मुख्य समस्याएं हैं: अपर्याप्त आगे पढ़ें और अत्यधिक। इसलिए, VxFS पर, आगे पढ़ें vpreunefs कमांड के read_pref_io और read_nstream मापदंडों का उपयोग करके कॉन्फ़िगर किया गया है। जब VxFS पर रीड-फॉरवर्ड सक्षम होता है, तो read_pref_io आकार के 4 ब्लॉक शुरू में अनुरोध किए जाते हैं। यदि प्रक्रिया क्रमिक रूप से पढ़ना जारी रखती है, तो 4 * read_pref_io * read_nstream पढ़ी जाती है।

उदाहरण

:
पठन_प्रक्रिया_यो = 256k और read_nstream = 4

इस प्रकार, आगे पढ़ा गया प्रारंभिक होगा: 4 * 256KB = 1024KB।
यदि अनुक्रमिक पढ़ना जारी रहता है, तो: 4 * 4 * 256KB = 4096KB

यह ध्यान दिया जाना चाहिए कि बाद के मामले में, 256KB ब्लॉक के साथ 16 अनुरोध डिस्क सबसिस्टम को लगभग एक साथ भेजे जाएंगे। यह छोटा नहीं है और थोड़े समय के लिए सरणी को अच्छी तरह से लोड कर सकता है। सामान्य स्थिति में, read_pref_io और read_nstream को सेट करने में कोई सामान्य सलाह देना मुश्किल है। विशिष्ट समाधान हमेशा सरणी और लोड की प्रकृति में डिस्क की संख्या पर निर्भर करते हैं। कुछ भारों के लिए, read_pref_io = 256k और read_nstream = 32 (बहुत अधिक) ठीक काम करते हैं। कभी-कभी, read_ahead पूरी तरह से बेहतर होता है। चूंकि सेटिंग सरल है और मक्खी पर सेट है, इसलिए इष्टतम मूल्य का चयन करना सबसे आसान है। केवल एक चीज जिसे सलाह दी जा सकती है वह हमेशा read_pref_io को 2 की शक्तियों में सेट करना है। या कम से कम इतना है कि वे OS कैश में डेटा ब्लॉक के कई आकार हैं। अन्यथा, परिणाम अप्रत्याशित हो सकते हैं।

ओएस बफर कैश का प्रभाव

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

आगे पढ़ने के साथ मुख्य मुद्दे:

1) आगे पढ़ने के लिए पर्याप्त नहीं है। आवेदन द्वारा अनुरोधित ब्लॉक आकार आगे पढ़ने के माध्यम से पढ़े गए ब्लॉक से बड़ा है। उदाहरण के लिए, 'cp' कमांड 1024 KB ब्लॉक में पढ़ सकता है, और रीड-फॉरवर्ड 256KB पढ़ने के लिए कॉन्फ़िगर किया गया है। यही है, आवेदन को संतुष्ट करने के लिए बस पर्याप्त डेटा नहीं है और एक और तुल्यकालिक I / O अनुरोध की आवश्यकता है। इस मामले में, आगे पढ़ने को चालू करने से गति में वृद्धि नहीं होगी।

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

3) आगे फाइल सिस्टम पढ़ने और आगे डिस्क सरणी पढ़ने के बीच संघर्ष
सौभाग्य से, यह एक अत्यंत दुर्लभ मामला है। कैश मेमोरी और लॉजिक से लैस अधिकांश आधुनिक डिस्क सरणियों में हार्डवेयर स्तर पर अपना स्वयं का पढ़ा हुआ तंत्र होता है। सरणी का तर्क स्वयं अनुक्रमिक पढ़ने को निर्धारित करता है और थोक में नियंत्रक भौतिक डिस्क से डेटा को सरणी कैश में पढ़ता है। यह डिस्क सबसिस्टम से प्रतिक्रिया समय को काफी कम कर सकता है और अनुक्रमिक रीड की गति बढ़ा सकता है। फ़ाइल सिस्टम के आगे पढ़ा गया एक नियमित सिंक्रोनस रीड की तुलना में थोड़ा अलग है और डिस्क सरणी नियंत्रक को भ्रमित कर सकता है। यह लोड की प्रकृति को नहीं पहचान सकता है और हार्डवेयर को आगे पढ़ने में सक्षम नहीं कर सकता है। उदाहरण के लिए, यदि डिस्क सरणी SAN (स्टोरेज एरिया नेटवर्किंग) के माध्यम से जुड़ा हुआ है और इसके लिए कई रास्ते हैं। लोड संतुलन के कारण, अतुल्यकालिक अनुरोध डिस्क सरणी के विभिन्न बंदरगाहों पर लगभग एक साथ आ सकते हैं। इस मामले में, अनुरोधों को नियंत्रक द्वारा संसाधित नहीं किया जा सकता है, क्योंकि वे सर्वर से भेजे गए थे। नतीजतन, सरणी अनुक्रमिक रीड्स को नहीं पहचानता है। ऐसी समस्याओं को हल करना सबसे लंबा और सबसे श्रमसाध्य हो सकता है। कभी-कभी समाधान कॉन्फ़िगरेशन क्षेत्र में निहित होता है, कभी-कभी यह आगे (यदि संभव हो) में से एक को अक्षम करने में मदद करता है, कभी-कभी घटकों में से एक के कोड को बदलना आवश्यक होता है।

प्रभाव उदाहरण पढ़ें

ग्राहक डेटाबेस के बैकअप समय से असंतुष्ट था। परीक्षण के रूप में, 50 जीबी आकार की एक एकल फ़ाइल का बैकअप लिया गया था। निम्नलिखित विभिन्न फ़ाइल सिस्टम सेटिंग्स के साथ तीन परीक्षणों के परिणाम हैं।

निर्देशिकाएँ ... 0
नियमित फाइलें ... १
- वस्तुएँ कुल ... १
कुल आकार ... 50.51 जीबी

1. आगे पढ़ें (प्रत्यक्ष IO)

रन टाइम ... 0:17:10
बैकअप स्पीड ... 71.99 एमबी / एस

2. मानक पढ़ने-आगे की सेटिंग्स (read_pref_io = 65536, read_nstream = 1)

रन टाइम ... 0:05:17
बैकअप स्पीड ... 163.16 एमबी / एस

3. बढ़ी हुई (जोरदार) रीड-फॉरवर्ड साइज (read_pref_io = 262144, read_nstream = 64)

रन टाइम ... 0:02:27
बैकअप स्पीड ... 222.91 एमबी / एस

जैसा कि आप उदाहरण से देख सकते हैं, काफी कम बैकअप समय को आगे पढ़ें। आगे के ऑपरेशन से पता चला कि सिस्टम पर अन्य सभी कार्यों ने सामान्य रूप से इतने बड़े रीड फॉरवर्ड साइज (परीक्षण 3) के साथ काम किया। आगे पढ़ने की अधिकता के कारण कोई समस्या नहीं देखी गई। नतीजतन, इन सेटिंग्स को छोड़ दिया गया था।