शायद, हर कोई पहले से ही जानता है कि सर्वर के मुख्य बाधाओं में से एक डिस्क सबसिस्टम है। यह विशेष रूप से वेब-सर्वर और बड़े DBMS पर ध्यान देने योग्य है। हार्ड ड्राइव के निर्माता प्रदर्शन के लिए एक निरंतर दौड़ में हैं, लेकिन भौतिकी के खिलाफ कोई बहस नहीं है - हार्ड ड्राइव का सिर प्रकाश की गति से बाहर नहीं लटक सकता है :)।

SSDs आते हैं, ऐसा लगता है, यहाँ यह है - खुशी! कोई मैकेनिक नहीं है, तब तक इंतजार करने की जरूरत नहीं है जब तक कि सिर वांछित बिंदु तक नहीं पहुंचता है (खासकर अगर डेटा खंडित है या ओएस एक ही बार में बहुत सी चीजों को पढ़ने की कोशिश कर रहा है)। लेकिन नहीं - महंगा, अविश्वसनीय, पर्याप्त जगह नहीं - सामान्य तौर पर, आप इसे सर्वर पर नहीं डाल सकते।

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

फ्लैशचैच क्या है?

हम फ़ेसबुक से फ्लैशकास्ट का उपयोग करते हैं, जिसके बारे में किसी कारण से हैबे पर लगभग कोई उल्लेख नहीं है।

Facebook के अंदर Flashcache का निर्माण MySQL (और अन्य DBMS) को गति देने के लिए किया गया था और 2010 में इसे ओपन सोर्स के रूप में पोस्ट किया गया था।

इसका सार सरल है: यह एसएसडी पर एक पारदर्शी कैश है। दो ब्लॉक डिवाइस (आमतौर पर hdd - "कहाँ से" और ssd - "जहाँ") के आधार पर, एक और कैश्ड एक बनाया जाता है, जिसका उपयोग सिस्टम द्वारा किया जाता है। एसएसडी पर पारदर्शी कैश आपको एचडीडी और एसएसडी दोनों के लाभों को संयोजित करने की अनुमति देता है।

यह सब कैसे शुरू हुआ

लगभग दो साल पहले, मेरे एक मित्र ने जर्मनी से कारों के चयन और बिक्री के साथ एक साइट परियोजना को गंभीरता से शुरू किया था। यह साइट पहले साझा होस्टिंग पर रहती थी और बहुत ही गूंगी थी - इंजन को जब और जिस तरह से समझ से बाहर किया गया था, तो मुख्य पृष्ठ लगभग 2-3 सेकंड के लिए जनरेट किया गया था। उपस्थिति में तेजी से वृद्धि ने एक अलग चाल की ओर कदम बढ़ाया, जिस पर वह अभी भी रहता है - फास्टवेप्स (हेत्ज़नर पुनर्विक्रेता) से प्रचारक i7। कुछ समय बाद, 8-10 के क्षेत्र में लोड औसत लगभग आदर्श बन गया - यह स्पष्ट हो गया कि कोड संशोधन करने के लिए आवश्यक था।

मैं कुछ समय के लिए एक बिंदु पर हंसा - मुख्य पृष्ठ पर एक शामिल था जो लगभग 3 सेकंड के लिए काम करता था और यह स्पष्ट नहीं था कि यह क्या कर रहा है, लेकिन इसके बिना काम नहीं किया। अंकेक्षण के परिणाम, हालांकि पूर्वानुमेय हैं, अभी भी दु: खद हैं: जो कुछ भी है उसे संपादित करने की तुलना में खरोंच (जो हम अभी कर रहे हैं) से सब कुछ फिर से लिखना आसान हो गया है। कैशिंग के साथ एसएसआई में कुछ ब्लॉकों को हटाने से थोड़ी मदद मिली (nginx + php-fpm वहां पहले से ही कताई थी), लेकिन कुछ करना पड़ा। सब कुछ नए सिरे से लिखने के लिए एक लंबा समय था (और मालिक अभी भी इस तरह के निर्णय से बहुत खुश नहीं है - हैलो, अंकल साशा! :)), वे वैकल्पिक समाधान की तलाश करने लगे। चेतना की धार सतह पर धकेलती हुई कहीं सोची - आप एसएसडी पर कैश कर सकते हैं। सोचा थपकी और डूब गया।

छह महीने पहले, एक मोड़ आया - RAID-1 में हार्ड ड्राइव ने एक बार में मार्लबोरो देश के लिए उड़ान भरी। जब हेट्ज़नर एचडीडी बदल रहा था, तो उन्होंने फैसला किया - मरने के लिए, इसलिए संगीत के साथ! और उन्होंने इसके अलावा एसएसडी को भी आदेश दिया।

इसका क्या आया?

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

तो, ग्राफ पर, बाएं से दाएं टुकड़े:

• टॉर्च के साथ काम करें
• शटडाउन ब्रेक
• HDD से सीधे फ्लैशकेच के बिना काम करना (गरीब zabbix ने लोड के कारण डेटा को बचाने का प्रबंधन नहीं किया - आइए इसे समझते हैं और इसे क्षमा करें)
• सब कुछ वापस करने के लिए एक ब्रेक (यहां मैंने एक गलती की, जिसके बारे में बाद में)
• टॉर्च के साथ काम करें
• त्रुटि सुधार ब्रेक
• सामान्य मोड में सामान्य ऑपरेशन (फ्लैशचैके के साथ)

सीपीयू लोड

विशाल ला के अच्छे पुराने दिनों में वापस जाना:

HDD और SSD लोड हो रहा है

यहाँ sda RAID (mdadm) के हिस्से के रूप में HDD है, sdc SSD है, जो कैश के रूप में काम करता है। एसडीबी - छापे से दूसरा एचडीडी, मैंने एक ग्राफ नहीं दिया - सब कुछ वहां एसडी के समान है।
HDD लोड हो रहा है:

जैसा कि आप देख सकते हैं, एचडीडी बहुत खराब हो गया है - प्रतिक्रिया समय 1 सेकंड तक पहुंचता है।

SSD, यहां सब कुछ सरल और स्पष्ट है:

साइट लोड समय

साइट के मुख्य पृष्ठ का लोडिंग समय मापा गया था। ब्लॉक कैशिंग के साथ कई एसएसआई हैं। यह मेरा पसंदीदा कार्यक्रम है:



मेरी राय में, परिणाम स्पष्ट हैं।

परिणाम और नुकसान

हमारा सर्वर बहुत अधिक संवेदनशील हो गया है, MySQL - तेज (कोई माप नहीं लिया गया था), और बाल - नरम और रेशमी।

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

• Flashcache 32-बिट सिस्टम पर काम नहीं करता है। कोड में किसी तरह की बेवकूफाना गलती है जिसे कोई ठीक करने की जल्दी में नहीं है - फेसबुक में 64-बिट वातावरण है।
• स्टार्टअप में डेबियन में फ्लैशकैच वॉल्यूम को इनिशियलाइज़ करने के लिए इनट्रामाफ़्स में हुक और स्क्रिप्ट शामिल हैं, लेकिन यह एलवीएम के शीर्ष पर संस्करणों के लिए काम नहीं करता है (क्योंकि लॉन्च के समय एलवीएम को आरंभीकृत नहीं किया गया है)। मैंने स्क्रिप्ट की शुरुआत में हैक करने का निर्णय लिया - / sbin / vgchange -ay । गलत, निश्चित रूप से, लेकिन फिर जल्दी से करना आवश्यक था।
• यह स्पष्ट रूप से माउंट करना संभव नहीं है और वॉल्यूम के ऊपर का उपयोग करना संभव है, जिसमें फ्लैशचेस चलता है (भले ही यह अक्षम हो)। ठीक है, यह है कि निश्चित रूप से, यह संभव है, लेकिन फिर फ्लैशचेच में परिवर्तनों के बारे में पता नहीं होगा। मेरे लिए, यह एक पुनः आरंभ (ग्राफ़ पर तीसरी विफलता) के बाद थोड़ी पीटी एफएस के साथ समाप्त हो गया। यह सही है - हम फ़्लैशचेस को रोकते हैं, इसे अक्षम करते हैं (डीएमएसटूप हटाएं), हमें वॉल्यूम के साथ जो कुछ भी करना है, एसएसडी (फ्लैशकैशे_डेस्ट्रो) पर फ्लैशचेस वॉल्यूम को हटाएं, फ्लैशचे को फिर से बनाएं। एफएस की जाँच जैसे ऑपरेशन के लिए, यह सब वैकल्पिक है, हम सिर्फ पहले से ही फ़्लैशस्कैच वॉल्यूम की जांच करते हैं।