छोटी फाइलों के बड़े पैमाने पर भंडारण के लिए रणनीति

Question

20 मिनट से अधिक पुरानी फाइलों के स्वत: छंटनी के साथ लाखों छोटी फ़ाइलों (औसत पर 50 केबी) के लिए बड़े पैमाने पर भंडारण की अच्छी रणनीति क्या है? मुझे वेब सर्वर से उन्हें लिखना और एक्सेस करना होगा।

मैं वर्तमान में ext4 का उपयोग कर रहा हूं, और हटाए जाने के दौरान (क्रॉन में निर्धारित) एचडीडी उपयोग 100% तक [स्पाश -8: 0] के साथ लोड करता है जो लोड बनाता है। यह लोड सर्वर पर अन्य अनुप्रयोगों में हस्तक्षेप करता है। जब कोई डिलीट नहीं होता है, तो अधिकतम एचडीडी उपयोग 0-5% होता है। स्थिति नेस्टेड और गैर-नेस्टेड निर्देशिका संरचनाओं के साथ समान है। सबसे बुरा हिस्सा यह है कि ऐसा लगता है कि पीक लोड के दौरान बड़े पैमाने पर हटाने सम्मिलन की दर से धीमी है, इसलिए निकालने की आवश्यकता वाली फ़ाइलों की मात्रा बड़ी और बड़ी हो जाती है।

मैंने शेड्यूलर (समय सीमा, सीएफक्यू, नोप) को बदलने की कोशिश की है, इससे मदद नहीं मिली है। मैंने स्क्रिप्ट को हटाने के लिए आयनिस सेट करने का भी प्रयास किया है, लेकिन इससे कोई मदद नहीं मिली है।

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

मैं भी = 2GB, innodb_log_file_size = 1GB, innodb_flush_log_on_trx_commit = 2 innodb_buffer_pool उपयोग करने के लिए,, MySQL 5.5 में डेटा संग्रहीत की कोशिश की है, ब्लॉब स्तंभ में InnoDB तालिका में InnoDB इंजन सेट के साथ है, लेकिन कार्यक्षमता भी बदतर था, HDD लोड हमेशा था 80% -100% (अपेक्षित, लेकिन मुझे कोशिश करनी थी)। तालिका केवल यूएलआईडी और डेटाटाइम कॉलम पर इंडेक्स के साथ बीएलओबी कॉलम, डेटाटाइम कॉलम और CHAR (32) latin1_bin UUID का उपयोग कर रही थी, इसलिए ऑप्टिमाइज़ेशन के लिए कोई जगह नहीं थी, और सभी प्रश्न इंडेक्स का उपयोग कर रहे थे।

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

इससे कोई फ़र्क नहीं पड़ता कि मैं कितनी बार ऑटो-प्रुनिंग स्क्रिप्ट चलाता हूं, प्रत्येक 1 सेकंड, प्रत्येक 1 मिनट, प्रत्येक 5 मिनट, प्रत्येक 30 मिनट, यह सर्वर को किसी भी तरह से बाधित कर रहा है।

मैंने इनोड मान को स्टोर करने की कोशिश की है और हटाते समय पुरानी फ़ाइलों को क्रमशः अपने इनोड नंबरों के साथ क्रमबद्ध करके हटा दिया है, लेकिन इससे मदद नहीं मिली।

का उपयोग CentOS 6. HDD एसएसडी RAID है 1.

क्या है जो स्वत: प्रूनिंग प्रदर्शन समस्या का समाधान होगा मेरे कार्य के लिए अच्छा और समझदार समाधान हो सकता है?

Answer 1

हटाना एक प्रदर्शन उपद्रव है क्योंकि डेटा और मेटाडाटा दोनों डिस्क पर नष्ट होने की आवश्यकता है।

क्या उन्हें वास्तव में अलग-अलग फाइलों की आवश्यकता है? क्या पुरानी फाइलों को वास्तव में हटाने की आवश्यकता है, या अगर वे ओवरराइट हो जाए तो यह ठीक है?

जवाब "नहीं" इन सवालों के दूसरे करने के लिए है, तो यह प्रयास करें:

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

प्रबंधित रूप से आकार वाली उपनिर्देशिका में फ़ाइलों को खंडित करके आप इस योजना में प्रदर्शन लाभ प्राप्त कर सकते हैं या नहीं।

आप कई चीजों को एक ही फ़ाइल में होने के साथ ठीक कर रहे हैं:

• समान आकार के फ़ाइलें रखें एक साथ एक इसी तरह के आकार फ़ाइलों की एक सरणी में ऑफसेट के रूप में हर एक को भंडारण के द्वारा। यदि प्रत्येक फ़ाइल 32k या 64k है, तो 32k भाग से भरा फ़ाइल और 64k भाग से भरा फ़ाइल रखें। अगर फाइल मनमानी आकार के हैं, तो दो की अगली शक्ति तक जाएं।
• आप आलसी हटाए यहाँ कैसे बासी प्रत्येक फ़ाइल है का ट्रैक रखने के द्वारा कर सकते हैं। यदि आप लिखने की कोशिश कर रहे हैं और कुछ पुराना है, तो फ़ाइल के अंत में जोड़ने के बजाय इसे ओवरराइट करें।

एक और सोचा: आप truncate() inode क्रम में लंबाई को 0 पर फ़ाइलों के सभी और फिर unlink() उन्हें ing ing द्वारा प्रदर्शन लाभ मिलता है? अज्ञान मुझे यह जानने से रोकता है कि क्या यह वास्तव में मदद कर सकता है, लेकिन ऐसा लगता है कि यह डेटा को एक साथ शून्य रखेगा और मेटाडेटा को समान रूप से एक साथ लिख देगा।

फिर भी एक और सोचा: XFS data=ordered साथ ext4 के अलावे एक कमजोर लिखने आदेश मॉडल है। क्या यह एक्सएफएस पर पर्याप्त तेज़ है?

Answer 2

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

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

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

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