हम फ़ोटो के वितरण में तेजी लाते हैं

हर सिस्टम प्रशासक जल्द या बाद में स्थिर सामग्री की धीमी वापसी की समस्या का सामना करता है।



यह लगभग इस तरह से ही प्रकट होता है: कभी-कभी एक 3 केबी तस्वीर को ऐसे लोड किया जाता है जैसे कि इसका वजन 3 एमबी, सीएसएस और जावा स्क्रिप्ट्स "छड़ी" (बहुत धीरे से बाहर देना) से शुरू होते हैं। आप ctrl + reload दबाएं - और, ऐसा लगता है, कोई समस्या नहीं है, फिर कुछ मिनटों के बाद सब कुछ फिर से दोहराता है।



"ब्रेक" का सही कारण हमेशा स्पष्ट नहीं होता है और हम नाज़िनक्स, होस्टर, "क्लॉग्ड" चैनल या "ब्रेक" या "छोटी गाड़ी" ब्राउज़र पर नज़र डालते हैं :)



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



इस लेख में मैं आपको इस समस्या का समाधान देने की पेशकश करता हूं, जो कि nginx वेब सर्वर के साथ SSD ड्राइव का उपयोग करने में व्यावहारिक अनुभव पर आधारित है।

कैसे समझें कि हार्ड ब्रेक?

लिनक्स पर, डिस्क सिस्टम की गति के मुद्दे सीधे iowait पैरामीटर (सीपीयू निष्क्रिय का प्रतिशत I / O के लिए इंतजार कर रहे हैं) से संबंधित हैं। इस पैरामीटर की निगरानी के लिए कई कमांड हैं: एमपीस्टेट , आईओस्टाट , सर । मैं आमतौर पर iostat 5 लॉन्च करता हूं (माप प्रत्येक 5 सेकंड में लिया जाएगा।)

मैं एक सर्वर के बारे में शांत हूं, जिसमें 0.5% तक की औसत आयोवाइट है । आपके "वितरण" के सर्वर पर सबसे अधिक संभावना यह पैरामीटर अधिक होगा। यह समझ में नहीं आता है कि iowait> 10% होने पर अनुकूलन में देरी न हो । आपका सिस्टम सूचना पढ़ने के बजाय हार्ड ड्राइव पर सिर हिलाने में बहुत समय व्यतीत करता है, इससे सर्वर पर अन्य प्रक्रियाओं का "ब्रेक लगाना" हो सकता है।

एक बड़े iowait के साथ क्या करना है?

जाहिर है, अगर आप डिस्क I / O की संख्या कम कर देते हैं, तो हार्ड ड्राइव आसान हो जाता है और iowait गिर जाएगा।

यहाँ कुछ सुझाव दिए गए हैं:

• Access_log को अक्षम करें
• फ़ाइल और निर्देशिका में अंतिम पहुंच की तारीख को अपडेट करने में अक्षम करें, सिस्टम को डिस्क पर संचालन लिखने को कैश करने की भी अनुमति देता है। ऐसा करने के लिए, निम्न विकल्पों के साथ फाइल सिस्टम को माउंट करें: async, noatime, बाधा = 0 । ('बाधा = 0' अनुचित जोखिम अगर डेटाबेस एक ही विभाजन पर है)
• आप गंदे vm.dirty_writeback_centisecs बफ़र्स को /etc/sysctl.conf में फ्लश करने के बीच का समय बढ़ा सकते हैं। मैंने vm.dirty_writeback_centisecs = 15000 सेट किया है
  
  
• क्या आप गलती से एक्सपायर अधिकतम निर्देश के बारे में भूल गए हैं?
• फ़ाइल डिस्क्रिप्टर कैशिंग को सक्षम करने के लिए यह अतिरेक नहीं होगा।
• क्लाइंट ऑप्टिमाइज़ेशन का अनुप्रयोग: css स्प्राइट्स, सभी css - एक फ़ाइल में, सभी js - एक फ़ाइल में

यह थोड़ा मदद करेगा और अपग्रेड होने तक बाहर रखने के लिए समय देगा। यदि परियोजना बढ़ रही है, तो आयोवाइट जल्द ही खुद को याद दिलाएगा। :)

लोहा अपग्रेड करें

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

सीपीयू अपग्रेड वितरण की गति को बिल्कुल भी प्रभावित नहीं करेगा, क्योंकि यह "धीमा" नहीं होता है! :)

क्यों एसएसडी

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

उस लेख के प्रकाशन के तुरंत बाद, किंग्स्टन SNE125-S2 / 64GB इंटेल x25e SSD के आधार पर हमारी कंपनी पर दिखाई दिया , जो आज भी सबसे अधिक लोड किए गए "वितरण" सर्वरों में से एक पर उपयोग किया जाता है।



एक साल के प्रयोगों के बाद, कई कमियां सामने आईं, जिनके बारे में मैं बात करना चाहूंगा:

• विज्ञापन की चाल: यदि SSD विज्ञापन कहता है कि अधिकतम पढ़ने की गति 250 एमबी / एस है , तो इसका मतलब है कि औसत पढ़ने की गति घोषित अधिकतम की ~ 75% (~ 190 एमबी / एस) होगी। मैं एमएलसी और एसएलसी के साथ इतना महंगा और सस्ता था।
• एक SSD की मात्रा जितनी अधिक होगी, इस ड्राइव पर 1MB की लागत उतनी ही अधिक होगी
• अधिकांश फ़ाइल सिस्टम SSDs पर उपयोग के लिए अनुकूलित नहीं हैं और डिस्क पर लिखने पर असमान भार पैदा कर सकते हैं।
• केवल सबसे आधुनिक (और इसलिए सबसे महंगा) RAID नियंत्रक एसएसडी को उनसे कनेक्ट करने के लिए अनुकूलित हैं
• SSD अभी भी महंगी तकनीक है

मैं SSD का उपयोग क्यों कर रहा हूं:

• विज्ञापन में झूठ नहीं है - तलाश-से-वास्तव में 0. के लिए प्रयास करता है। यह आपको बड़ी संख्या में फ़ाइलों के समानांतर "वितरण" में आयोवाइट को कम करने की अनुमति देता है।
• हां, वास्तव में, रीराइट साइकल की संख्या सीमित है, लेकिन हम इसके बारे में जानते हैं और नीचे वर्णित विधि का उपयोग करके पुन: लिखने योग्य जानकारी की मात्रा को कम कर सकते हैं
• स्मार्ट कंट्रोलर के साथ एसएलसी (सिंगल-लेवल सेल) तकनीक का उपयोग करने वाले डिस्क पहले से ही उपलब्ध हैं, जो पुनर्मिलन चक्रों की संख्या है जो साधारण एमएलसी एसएसडी से अधिक परिमाण का एक आदेश है
• आधुनिक फाइल सिस्टम (जैसे btrfs ) पहले से ही SSD के साथ सही तरीके से काम करने में सक्षम हैं
• एक नियम के रूप में, एक कैशिंग सर्वर को थोड़ी मात्रा में कैश स्थान की आवश्यकता होती है (हमारे पास 100-200G है), जो 1 SSD पर फिट हो सकता है। यह पता चला है कि यह कई एसएएस डिस्क के साथ हार्डवेयर RAID सरणी पर आधारित समाधान की तुलना में काफी सस्ता है

SSD कैश कॉन्फ़िगर करें

फ़ाइल सिस्टम चयन

प्रयोग की शुरुआत में, किंग्स्टन SNE125-S2 / 64GB पर ext4 स्थापित किया गया था। इंटरनेट पर आपको लॉग ऑफ करने, फ़ाइलों तक पहुंचने की अंतिम तारीख आदि के बारे में कई सिफारिशें मिलेंगी। सब कुछ पूरी तरह से और लंबे समय तक काम किया। सबसे महत्वपूर्ण बात यह है कि यह आपको सूट नहीं करता - बड़ी संख्या में छोटे चित्रों के साथ 1-5K 64G SSD पर, आधे से कम फिट - ~ 20G। मुझे संदेह होने लगा कि मेरे SSD का तर्कसंगत उपयोग नहीं किया जा रहा है।



मैंने कर्नेल को 2.6.35 में अपग्रेड किया और प्रयास करने का फैसला किया (अभी भी प्रायोगिक) btrfs, यह इंगित करने का एक अवसर है कि बढ़ते समय ssd माउंट किया जाता है। डिस्क को विभाजन में विभाजित नहीं किया जा सकता है, जैसा कि प्रथागत है, लेकिन एक पूरे के रूप में स्वरूपित है।



एक उदाहरण:

mkfs.btrfs /dev/sdb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



UUID = 7db90cb2-8a57-42e3-86bc-013cc0bcb30e / var / www / ssd btrfs डिवाइस = / dev / sdb, डिवाइस = / dev / sdc, डिवाइस = / dev / sdd, noatime, ssd, nobarrier, एनस्ट्रियर। , noacl, notreelog 1 2



आप कमांड का उपयोग करके एक स्वरूपित डिस्क के यूयूआईडी का पता लगा सकते हैं

 blkid /dev/sdb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

नतीजतन, 41 जी से अधिक डिस्क पर "चढ़ गए" (ext4 पर 2 गुना अधिक)। उसी समय, वितरण की गति को नुकसान नहीं हुआ (क्योंकि इओवाइट में वृद्धि नहीं हुई)।



हम SSD से RAID एकत्र करते हैं

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



Btrfs डिस्क पर 3 प्रकार के डेटा को सहेजता है: फ़ाइल सिस्टम के बारे में डेटा, मेटाडेटा ब्लॉकों के पते (डिस्क पर मेटाडेटा की हमेशा 2 प्रतियां होती हैं) और, वास्तव में, डेटा स्वयं (फ़ाइल सामग्री)। प्रयोगात्मक रूप से, मैंने पाया कि हमारी निर्देशिका संरचना में "संपीड़ित" मेटाडेटा एक अनुभाग में सभी डेटा का ~ 30% है। मेटाडेटा सबसे गहन रूप से परिवर्तित ब्लॉक है, क्योंकि किसी फाइल, फाइल ट्रांसफर, एक्सेस राइट्स का बदलाव मेटाडेटा ब्लॉक को ओवरराइट कर देता है। वह क्षेत्र जहाँ डेटा को केवल संग्रहीत किया जाता है, कम बार ओवरराइट किया जाता है। इसलिए हम btrfs की सबसे दिलचस्प विशेषता पर आते हैं: यह सॉफ़्टवेयर RAID-सरणियाँ बनाना और स्पष्ट रूप से इंगित करना है कि किस मेटाडेटा पर डेटा संग्रहीत करने के लिए डिस्क।



एक उदाहरण:

 mkfs.btrfs -m single /dev/sdc -d raid0 /dev/sdb /dev/sdd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परिणामस्वरूप, मेटाडेटा / dev / sdc और / dev / sdb और / dev / sdd पर डेटा बनाया जाएगा, जो कि छीन छापे में एकत्र किया जाएगा। इसके अलावा, आप मौजूदा सिस्टम से अधिक डिस्क कनेक्ट कर सकते हैं, डेटा बैलेंस कर सकते हैं, आदि।



UUID btrfs RAID का पता लगाने के लिए, रन करें:

 btrfs device scan
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ध्यान दें: btrfs- राइड के साथ काम करने की ख़ासियत: प्रत्येक आरओ सरणी को माउंट करने से पहले और btrfs मॉड्यूल को लोड करने के बाद, आपको कमांड चलाना होगा: btrfs डिवाइस स्कैन । Fstab के माध्यम से स्वचालित माउंटिंग के लिए, आप माउंट लाइन में डिवाइस विकल्पों को जोड़कर 'btrfs डिवाइस स्कैन' के बिना कर सकते हैं। एक उदाहरण:

 /dev/sdb /mnt btrfs device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,device=/dev/sde
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

प्रॉक्सी के बिना nginx पर कैशिंग

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

साइट के स्टोरेज सर्वर और उपयोगकर्ताओं के बीच एक "वितरण" सर्वर है, जिसका कार्य स्टोरेज सर्वर से लोड को निकालना है और किसी भी संख्या के क्लाइंट के लिए निर्बाध "वितरण" सुनिश्चित करना है।



वितरण सर्वर पर बोर्ड पर btrfs के साथ एक या अधिक SSDs स्थापित करें। यह सीधे nginx कॉन्फ़िगरेशन को प्रॉक्सी_cache पर आधारित करता है। लेकिन हमारे सिस्टम के लिए उसके कई नुकसान हैं:

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

हम कैशिंग के लिए एक अलग दृष्टिकोण लेंगे। एक विचार हिल्लोद सम्मेलनों में आया। कैश सेक्शन 2 में cache0 और cache1 निर्देशिका बनाएं। सभी प्रॉक्सी फाइलें कैश 0 (प्रॉक्सी_स्टोर का उपयोग करके) में बचाई जाती हैं। nginx को फ़ाइल की उपलब्धता की जाँच करने के लिए मजबूर किया जाता है (और क्लाइंट को फ़ाइल दें) पहले cache0 में और फिर cache1 में। यदि फ़ाइल नहीं मिली है, तो फ़ाइल के लिए संग्रहण सर्वर पर जाएँ, फिर इसे cache0 में सहेजें।

कुछ समय (सप्ताह / माह / तिमाही) के बाद, cache1 को हटा दें, cache0 को cache1 में बदल दें और एक खाली cache0 बनाएं। हम कैश 1 अनुभाग में एक्सेस लॉग का विश्लेषण करते हैं और उन फ़ाइलों को लिंक करते हैं जो इस अनुभाग से कैश 0 में अनुरोध किए गए हैं।



यह विधि SSD पर लिखने के संचालन को महत्वपूर्ण रूप से कम कर सकती है, क्योंकि किसी फ़ाइल को फिर से लिखना अभी भी पूरी तरह से फ़ाइल को फिर से लिखने से कम है। इसके अलावा, आप कई एसएसडी से एक छापे एकत्र कर सकते हैं, जिनमें से 1 नियमित डेटा के लिए मेटाडेटा और एमएलसी एसएसडी के लिए एसएलसी होगा। (हमारे सिस्टम पर, मेटाडेटा कुल डेटा वॉल्यूम का लगभग 30% है) । लिंक करते समय, केवल मेटाडेटा को ओवरराइट किया जाएगा!



Nginx कॉन्फ़िगरेशन उदाहरण

 log_format cache0 '$request'; # ... server { expires max; location / { root /var/www/ssd/cache0/ ; try_files $uri @cache1; access_log off; } location @cache1 { root /var/www/ssd/cache1; try_files $uri @storage; access_log /var/www/log_nginx/img_access.log cache0; } location @storage { proxy_pass http://10.1.1.1:8080/$request_uri; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /var/www/img_temp/; #    SSD! root /var/www/ssd/cache0/; access_log off; } # ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cache0 और cache1 रोटेशन के लिए स्क्रिप्ट

मैंने बैश पर कई स्क्रिप्ट लिखी हैं जो आपको पहले वर्णित रोटेशन योजना को लागू करने में मदद करेंगे। यदि आपके कैश का आकार सैकड़ों गीगाबाइट में मापा जाता है और कैश में सामग्री की मात्रा लाखों में है, तो निम्न कमांड के साथ एक पंक्ति में कई बार रोटेशन के तुरंत बाद ria_ssd_cache_mover.sh स्क्रिप्ट चलाने की सलाह दी जाती है:

 for i in `seq 1 10`; do ria_ssd_cache_mover.sh; done;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस कमांड को प्रयोगात्मक रूप से चलाने के लिए समय निर्धारित करें। उसने लगभग एक दिन मेरे लिए काम किया। अगले पर दिन, हर घंटे क्रोन पर ria_ssd_cache_mover.sh का प्रक्षेपण सेट करें।



डॉस भंडारण सर्वर के खिलाफ संरक्षण

यदि संग्रहण सर्वर कमजोर है, और आपके सिस्टम का गला घोंटने के लिए उत्सुक हैं, तो आप वर्णित समाधान के साथ Secure_link मॉड्यूल का उपयोग कर सकते हैं

उपयोगी लिंक

• Btrfs पर सबसे पूर्ण प्रलेखन (संलग्न)
• रूसी में btrfs के बारे में
• अच्छी तरह से साइरिल मोकेविन की रिपोर्ट के विषय को पूरक करता है "भंडारण, प्रसंस्करण और स्थैतिक की वापसी"

UPD1: फिर भी, मैं आपको कर्नेल> = 2.6.37 और पुराने का उपयोग करने की सलाह देता हूं, क्योंकि मैं हाल ही में मेटाडाटा के साथ एसएसडी पर अंतरिक्ष अतिप्रवाह के कारण 2.6.35 पर एक बड़ा कैश क्रैश हुआ था। नतीजतन, विदेशी कई SSDs को प्रारूपित करेगा और btrfs छापे को फिर से इकट्ठा करेगा। :(