बड़ी संख्या में छोटी फ़ाइलों के साथ काम करने पर हक्स

लेख का विचार "सहज रूप से कुछ के बारे में" पर टिप्पणियों में एक चर्चा से अनायास पैदा हुआ था।



तथ्य यह है कि हमारी सेवाओं की आंतरिक बारीकियों में बड़ी संख्या में छोटी फ़ाइलों का भंडारण है। फिलहाल, हमारे पास ऐसे डेटा के सैकड़ों टेराबाइट हैं। और हम कुछ स्पष्ट और बहुत स्पष्ट नहीं थे और सफलतापूर्वक उन पर चले।

इसलिए, मैं अपना अनुभव साझा करता हूं, शायद कोई काम आएगा।

समस्या एक: "डिवाइस पर कोई स्थान नहीं बचा"

जैसा कि उपरोक्त लेख में उल्लेख किया गया है, समस्या यह है कि फ़ाइल सिस्टम पर मुफ्त ब्लॉक हैं, लेकिन इनोड खत्म हो गया है।

आप df -ih साथ उपयोग किए गए और मुफ्त df -ih की संख्या की जांच कर सकते हैं:



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

लिनक्स पहले से ही विभिन्न शेष के साथ विकल्प प्रदान कर चुका है, और ये सभी पूर्व-गणना कॉन्फ़िगरेशन /etc/mke2fs.conf फ़ाइल में हैं।
इसलिए, mke2fs के माध्यम से फ़ाइल सिस्टम के प्रारंभिक आरंभ के दौरान, आप वांछित प्रोफ़ाइल निर्दिष्ट कर सकते हैं।

यहाँ फ़ाइल से कुछ उदाहरण दिए गए हैं:

  small = { blocksize = 1024 inode_size = 128 inode_ratio = 4096 } big = { inode_ratio = 32768 } largefile = { inode_ratio = 1048576 blocksize = -1 } 

जब आप mke2fs पर कॉल करते हैं तो आप -T विकल्प के साथ वांछित उपयोग के मामले का चयन कर सकते हैं। यदि कोई तैयार समाधान नहीं है, तो आप आवश्यक मापदंडों को मैन्युअल रूप से सेट कर सकते हैं।

अधिक विवरण mke2fs.conf और mke2fs.conf मैनुअल में वर्णित हैं।

उपरोक्त लेख में वर्णित एक विशेषता - आप डेटा ब्लॉक का आकार निर्धारित कर सकते हैं। जाहिर है, बड़ी फ़ाइलों के लिए, यह बड़ी ब्लॉक आकार के लिए, छोटी फ़ाइलों के लिए - एक छोटे से में समझ में आता है।

हालांकि, यह प्रोसेसर वास्तुकला के रूप में इस तरह के एक दिलचस्प विशेषता पर विचार करने के लायक है।
मैंने एक बार सोचा था कि मुझे बड़ी फोटो फ़ाइलों के लिए एक बड़े ब्लॉक आकार की आवश्यकता है। यह घर पर था, एआरएम आर्किटेक्चर पर होम फाइल नाम डब्ल्यूडी पर। बिना किसी हिचकिचाहट के, मैंने मानक 4k के बजाय ब्लॉक आकार को 8k या 16k पर सेट किया, पहले बचत को मापा। और सब कुछ उस क्षण तक अद्भुत था जब भंडारण स्वयं विफल नहीं हुआ, जबकि डिस्क जीवित थी। डिस्क को एक नियमित इंटेल प्रोसेसर के साथ एक नियमित कंप्यूटर में डाल दिया, मुझे एक आश्चर्य मिला: असमर्थित ब्लॉक आकार। रवाना हुए। डेटा है, सब कुछ ठीक है, लेकिन पढ़ना असंभव है। प्रोसेसर i386 और जैसे कि ब्लॉक आकार के साथ काम करना नहीं जानते हैं जो मेमोरी पेज के आकार से मेल नहीं खाते हैं, लेकिन यह बिल्कुल 4k है। सामान्य तौर पर, उपयोगकर्ता स्थान से उपयोगिताओं के उपयोग के साथ मामला समाप्त हो गया, सब कुछ धीमा और दुखद था, लेकिन डेटा सहेजा गया था। कौन परवाह करता है - Google उपयोगिता का नाम fuseext2 । नैतिक: या तो सभी मामलों के बारे में पहले से सोचें, या एक सुपर हीरो का निर्माण न करें और गृहिणियों के लिए मानक सेटिंग्स का उपयोग करें।

युपीडी। उपयोगकर्ता की टिप्पणी के अनुसार, berez स्पष्ट करता है कि i386 के लिए ब्लॉक का आकार 4k से अधिक नहीं होना चाहिए, लेकिन इसका ठीक 4k होना आवश्यक नहीं है, अर्थात्। वैध 1k और 2k।

इसलिए, हमने समस्याओं को कैसे हल किया।

सबसे पहले, हमें एक समस्या का सामना करना पड़ा जब एक बहु-टेराबाइट डिस्क डेटा से भरा था, और हम फ़ाइल सिस्टम कॉन्फ़िगरेशन को फिर से नहीं कर सके।

दूसरे, निर्णय तत्काल था।

नतीजतन, हम इस निष्कर्ष पर पहुंचे कि हमें फाइलों की संख्या को कम करके शेष राशि को बदलना होगा।
फ़ाइलों की संख्या कम करने के लिए, फ़ाइलों को एक सामान्य संग्रह में रखने का निर्णय लिया गया। हमारी बारीकियों को ध्यान में रखते हुए, हमने सभी फाइलों को एक निश्चित अवधि के लिए एक संग्रह में रख दिया, और रात में दैनिक रूप से अभिलेखीय कार्य किया।

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

ग्राहक nginx के माध्यम से फ़ाइलें लेते हैं, और पुराने API के अनुसार, फ़ाइल का नाम निर्दिष्ट किया जाता है, उदाहरण के लिए:

 http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5 

फ़्लाई पर फ़ाइलों को अनपैक करने के लिए, हमने nginx-unzip-मॉड्यूल मॉड्यूल ( https://github.com/youzee/nginx-unzip-module ) को ढूंढा और कनेक्ट किया और दो अपस्ट्रीम सेट अप किए।

परिणाम इस विन्यास है:



सेटिंग्स में दो होस्ट इस तरह दिखे:

 server { listen *:8081; location / { root /home/filestorage; } } 

 server { listen *:8082; location ~ ^/hydra/(\d+)/(\d+)/(.*)$ { root /home/filestorage; file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip"; file_in_unzip_extract "$2/$3"; file_in_unzip; } } 

और अपस्ट्रीम nginx पर अपस्ट्रीम कॉन्फ़िगरेशन:

 upstream storage { server server.com:8081; server server.com:8082; } 

यह कैसे काम करता है:

• क्लाइंट के सामने nginx चला जाता है
• फ्रंट नेग्नेक्स पहले अपस्ट्रीम से फाइल देने की कोशिश करता है, यानी। सीधे फाइल सिस्टम से
• यदि कोई फ़ाइल नहीं है, तो यह दूसरी अपस्ट्रीम से देने की कोशिश करता है, जो संग्रह के अंदर फ़ाइल को खोजने की कोशिश करता है

दूसरी समस्या: फिर से, "डिवाइस पर कोई स्थान नहीं बचा"

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

यह पता चला है।

यह कुछ इस तरह दिखता है:



चेकिंग इनोड्स ने कुछ नहीं दिया - उनमें से बहुत सारे मुफ्त हैं।
जगह की जाँच करना एक ही है।
हमने सोचा था कि निर्देशिका में बहुत अधिक फाइलें हो सकती हैं, लेकिन इसकी एक सीमा है, लेकिन फिर से नहीं: प्रति निर्देशिका अधिकतम फाइलें: ~ 1.3 × 10 ^ 20

यदि आप नाम बदलते हैं, तो हाँ, और आप एक फ़ाइल बना सकते हैं।
निष्कर्ष फ़ाइल के नाम में एक समस्या है।

आगे की खोजों से पता चला कि निर्देशिका सूचकांक का निर्माण करते समय समस्या हैशिंग एल्गोरिथम में है, बड़ी संख्या में फाइलों के साथ सभी आगामी परिणाम के साथ टकराव होते हैं। अधिक विवरण यहां देखे जा सकते हैं: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

आप इस विकल्प को अक्षम कर सकते हैं, लेकिन ... सभी फ़ाइलों के माध्यम से छांटने पर नाम से फ़ाइल की खोज अप्रत्याशित रूप से लंबी हो सकती है।

  tune2fs -O "^dir_index" /dev/sdb3 

सामान्य तौर पर, वर्कअराउंड कैसे काम कर सकता है।

नैतिक: एक निर्देशिका में कई फाइलें आमतौर पर खराब होती हैं। यह आवश्यक नहीं है।

आमतौर पर ऐसे मामलों में वे फ़ाइल नाम के पहले अक्षर या कुछ अन्य मापदंडों द्वारा उपनिर्देशिकाएँ बनाते हैं, उदाहरण के लिए, तारीखों द्वारा, ज्यादातर मामलों में यह बचाता है।
लेकिन छोटी फ़ाइलों की कुल संख्या अभी भी खराब है, भले ही उन्हें निर्देशिकाओं में विभाजित किया गया हो - फिर पहली समस्या देखें।

तीसरी समस्या: फ़ाइलों की सूची कैसे देखें, अगर उनमें से बहुत सारे हैं

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

मानक समाधान ls ।
ठीक है, देखते हैं कि 4772098 फाइलों पर क्या होता है:

 $ time ls /home/app/express.repository/offercache/ >/dev/null real 0m30.203s user 0m28.327s sys 0m1.876s 

30 सेकंड ... यह बहुत अधिक हो जाएगा। और अधिकांश समय उपयोगकर्ता अंतरिक्ष में फ़ाइलों को संसाधित करने के लिए लेता है, और कर्नेल पर बिल्कुल भी नहीं।

लेकिन एक समाधान है:

 $ time find /home/app/express.repository/offercache/ >/dev/null real 0m3.714s user 0m1.998s sys 0m1.717s 

3 सेकंड 10 गुना तेज।
हुर्रे!

युपीडी।

Berez उपयोगकर्ता से एक और भी तेज समाधान ls सॉर्टिंग को अक्षम करना है

 time ls -U /home/app/express.repository/offercache/ >/dev/null real 0m2.985s user 0m1.377s sys 0m1.608s 

चौथी समस्या: फाइलों के साथ काम करते समय बड़े एलए

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

सबसे उचित बात आप एक SSD का उपयोग करना चाहते हैं। वास्तव में अच्छा है। एकमात्र सवाल मल्टी-टेराबाइट एसएसडी की लागत है।

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

nice - क्रमशः प्रक्रिया की प्राथमिकता को कम करता है, शेडयूलर अधिक समय स्लाइस को अन्य, अधिक प्राथमिकता प्रक्रियाओं में वितरित करता है।
हमारे व्यवहार में, इसने अधिकतम को अच्छा सेट करने में मदद की (19 न्यूनतम प्राथमिकता है, -20 (माइनस 20) अधिकतम है)।

ionice - तदनुसार इनपुट / आउटपुट की प्राथमिकता को समायोजित करता है (I / O शेड्यूलिंग)

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

 echo 1000 > /proc/sys/dev/raid/speed_limit_max 

पांचवीं समस्या: वास्तविक समय में फ़ाइलों को सिंक्रनाइज़ कैसे करें

हमारे पास सभी बड़ी संख्या में फाइलें हैं, जिनसे बचने के लिए दूसरे सर्वर तक बैकअप की आवश्यकता होती है ... फाइलें लगातार लिखी जा रही हैं, इसलिए, कम से कम नुकसान होने के लिए, आपको उन्हें जल्दी से जल्दी कॉपी करने की आवश्यकता है।

मानक समाधान: SSH पर रु।

यह एक अच्छा विकल्प है, जब तक कि आपको हर कुछ सेकंड में एक बार करने की आवश्यकता न हो। और बहुत सारी फाइलें हैं। यहां तक ​​कि अगर आप उन्हें कॉपी नहीं करते हैं, तब भी आपको किसी तरह समझने की जरूरत है कि क्या बदल गया है, और कई मिलियन फाइलों की तुलना करने का समय और डिस्क पर लोड है।

यानी हर बार तुलना शुरू किए बिना, हमें तुरंत पता होना चाहिए कि क्या कॉपी करना है।

मोक्ष - lsyncd । Lsyncd - लाइव सिंकिंग (मिरर) डेमन । यह rsync के माध्यम से भी काम करता है, लेकिन यह अतिरिक्त रूप से inotify और fsevents का उपयोग करके परिवर्तन के लिए फ़ाइल सिस्टम की निगरानी करता है और केवल उन फ़ाइलों के लिए प्रतिलिपि बनाना शुरू करता है जो दिखाई या बदल गए हैं।

छठी समस्या: कैसे समझें कि डिस्क को कौन लोड करता है

हर कोई शायद यह जानता है, लेकिन फिर भी पूर्णता के लिए: डिस्क सबसिस्टम की निगरानी के लिए iotop कमांड है - top तरह, लेकिन उन प्रक्रियाओं को दिखाता है जो डिस्क का सक्रिय रूप से उपयोग करते हैं।



वैसे, अच्छा पुराना शीर्ष यह भी स्पष्ट करता है कि डिस्क के साथ समस्याएं हैं या नहीं। इसके लिए दो सबसे उपयुक्त पैरामीटर हैं: लोड औसत और IOwait ।



पहले एक से पता चलता है कि सेवा कतार में कितनी प्रक्रियाएं हैं, आमतौर पर 2 से अधिक - कुछ पहले से ही गलत हो रहा है। बैकअप सर्वर पर सक्रिय प्रतिलिपि बनाने के साथ, हम 6-8 तक की अनुमति देते हैं, जिसके बाद स्थिति को असामान्य माना जाता है।

दूसरा यह है कि प्रोसेसर डिस्क संचालन के साथ कितना व्यस्त है। IOwait> 10% चिंता का कारण है, हालांकि एक विशिष्ट लोड प्रोफ़ाइल वाले सर्वर पर यह 40-50% स्थिर है, और यह वास्तव में आदर्श है।

मैं यहां समाप्त होऊंगा, हालांकि शायद कई बिंदु हैं जिनका हमें सामना नहीं करना पड़ा है, मुझे दिलचस्प वास्तविक मामलों की टिप्पणियों और विवरणों की प्रतीक्षा करने में खुशी होगी।