उपनिर्देशिका प्रभाव की संख्या लिनक्स पर पढ़ने / लिखने के प्रदर्शन को कैसे प्रभावित करती है?

Question

मुझे Linux CentOS सर्वर पर एक EXT3 स्वरूपित ड्राइव मिली है। यह एक वेब ऐप डेटा ड्राइव है और इसमें प्रत्येक उपयोगकर्ता खाते के लिए एक निर्देशिका है (25,000 उपयोगकर्ता हैं)। प्रत्येक फ़ोल्डर में वे फ़ाइलें होती हैं जो उपयोगकर्ता ने अपलोड की हैं। कुल मिलाकर, इस ड्राइव में लगभग 250GB डेटा है।

क्या इन सभी निर्देशिकाओं के प्रभाव से ड्राइव को पढ़ना / लिखना प्रदर्शन को प्रभावित करता है? क्या यह कुछ अन्य प्रदर्शन पहलू को प्रभावित करता है जिनसे मैं अवगत नहीं हूं?

क्या इस तरह से संरचित चीजों के साथ कुछ गलत या गलत है? शायद फाइल सिस्टम का सिर्फ गलत विकल्प?

मैंने हाल ही में दो डेटा ड्राइव को मर्ज करने की कोशिश की है और महसूस किया है कि EXT3 32,000 उपनिर्देशिकाओं तक सीमित है। इससे मुझे आश्चर्य हुआ कि मैं क्यों। यह मूर्खतापूर्ण लगता है कि मैंने इसे इस तरह से बनाया है, प्रत्येक फ़ाइल पर विचार करना एक अद्वितीय आईडी है जो डेटाबेस में एक आईडी से मेल खाती है। काश ...

Comments

किसी भी कारण से आप ऐसा कुछ नहीं कर सकते homes/u/username, homes/j/joeblow,homes/s/somebody,...?

— Zoredache

@Zoredache द्वारा सूचीबद्ध वह समूहीकरण विधि है कि हम हमेशा इसे दिन में वापस कैसे करते हैं (बड़ी मात्रा में उपयोगकर्ताओं के साथ बहुत छोटी मशीनों पर)।

— ब्रायन नोब्लुच

@Zoredache यह गरीब आदमी बी-ट्री हैशिंग जैसा दिखता है। लेकिन यह धीमा है क्योंकि यह कर्नेल स्थान में नहीं चल रहा है, और थोड़ी अधिक डिस्क रीड की आवश्यकता है और यह अच्छी तरह से संतुलित नहीं हो सकता है। Ext3 और ext4 का htree बेहतर है। इसे भी देखें: ext2.sourceforge.net/2005-ols/paper-html/node3.html

— Mircea Vutcovici

आपको उत्तर देना चाहिए ...

— ewwhite

Answer 1

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

XFS फाइल सिस्टम निर्देशिका संरचना के इस प्रकार के लिए बेहतर है। ext4 आजकल सिर्फ ठीक है। निर्देशिका पर पहुंच और संचालन बस उपनिर्देशिका और फ़ाइलों की संख्या में वृद्धि को धीमा कर देगा। यह एक्स 3 के तहत बहुत स्पष्ट है और एक्सएफएस पर ऐसा नहीं है।

Comments

एक्सएफएस निश्चित रूप से इस संरचना के लिए उपयोग करने के लिए फिल्म सिस्टम है क्योंकि यह लाखों उपनिर्देशिकाओं का समर्थन करता है और प्रदर्शन ऐसा प्रतीत नहीं होता है जैसे EXT3 जहां प्रभाव महत्वपूर्ण है ... एक ग्राफ के आधार पर मैंने देखा कि मुझे अब नहीं मिल सकता है।

— टी। ब्रायन जोन्स

Answer 2

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

सिवाय इसके कि यह कब होता है।

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

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

संपादित करें :

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

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

उदाहरण के लिए: मान लें कि आपके पास 'foo-999999.txt' और 'natalieportman.jpeg' के माध्यम से 'foo-000000.txt' नामक एक लाख फाइलों के साथ एक निर्देशिका है। ये होंगे तेज:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

ये असफल होंगे, लेकिन तेजी से असफल भी होंगे:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

ये धीमे होंगे, भले ही वे बहुत कम परिणाम दें; यहां तक ​​कि जो असफल होते हैं, वे सभी प्रविष्टियों को स्कैन करने के बाद विफल होते हैं:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Answer 3

पहले सुनिश्चित करें कि ext3 विभाजन में dir_indexध्वज सेट है।

sudo dumpe2fs /dev/sdaX |grep --color dir_index

यदि यह गायब है, तो आप इसे सक्षम कर सकते हैं। आपको फ़ाइल सिस्टम को अनमाउंट करने की आवश्यकता है, फिर चलाएं:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

फिर फाइलसिस्टम को माउंट करें।

Answer 4

इससे कोई फर्क नहीं पड़ता है जब तक कि आप प्रति निर्देशिका सीमा में अतिरिक्त 32,000 नामों को नहीं मारते। Ext4 को अपग्रेड करने के आसपास हो सकता है, साथ ही ext4 के अन्य लाभ हैं।

Answer 5

जितनी अधिक प्रविष्टियाँ (फाइलें, और dirs) आपके पास एक एकल निर्देशिका के अंदर हैं, धीमी पहुंच होने वाली है। यह हर फाइलसिस्टम के लिए सही है, हालांकि कुछ दूसरों की तुलना में खराब हैं।

एक बेहतर समाधान इस तरह एक निर्देशिका पदानुक्रम बनाने के लिए है:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

और अगर आपको अभी भी बेहतर प्रदर्शन की आवश्यकता है, तो आप कई स्तरों का विस्तार कर सकते हैं:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

अधिकांश मेल सिस्टम इस ट्रिक का उपयोग अपनी मेल कतार फ़ाइलों के साथ करते हैं।

इसके अलावा, मैंने पाया है कि कुछ filesystems के साथ, बस एक निर्देशिका में पिछले कई प्रविष्टियों में था कि निर्देशिका का उपयोग धीमा कर देगा। ls -ldनिर्देशिका प्रविष्टि के आकार को देखने के लिए निर्देशिका पर एक ही करें। यदि यह कई एमबी या अधिक है और निर्देशिका अपेक्षाकृत खाली है, तो आपको खराब प्रदर्शन मिल सकता है। निर्देशिका को रास्ते से हटाएं, एक ही नाम और अनुमतियों और स्वामित्व के साथ एक नया बनाएं, और फिर अपनी पुरानी निर्देशिका की सामग्री को नए में स्थानांतरित करें। मैंने कई बार मेल सर्वर को गति देने के लिए इस ट्रिक का उपयोग किया है जो कि फाइल सिस्टम द्वारा धीमा हो गया था।

Answer 6

मैंने हाल ही में एक स्टोरेज सर्वर विकसित किया है, जिसमें लाखों-लाखों फाइलें और सैकड़ों-हज़ारों डायरेक्टरीज़ बनाने की ज़रूरत है। मैंने एक्सएफएस की तुलना एक्सटी 4 और रीजरफ्स के साथ की। मैंने पाया कि मेरे मामले में एक्स 4 एक्सएफएस की तुलना में थोड़ा तेज था। Reiser दिलचस्प था लेकिन उसकी सीमाएँ थीं इसलिए उसे गिरा दिया गया था। मैंने यह भी पाया कि ext4 ext3 की तुलना में काफी तेज था।

जब आपको प्रति डायरेक्टरी बहुत सारी फाइलें मिल जाती हैं, तो फाइल ओपन होने में समय लगता है। फ़ाइल I / O नहीं है। फ़ाइल विलोपन समय भी ग्रस्त है। हालाँकि, यह ext4 पर बहुत धीमा नहीं है। हालांकि ext3 के तहत यह काफी ध्यान देने योग्य है। XFS और ext4 इस पर काफी तेज हैं।

जब मैंने पिछली बार XFS को देखा था और एक्स 4 पर एक्सएफएस का उपयोग करने के फायदे और नुकसान का वजन कर रहा था, तो मुझे एक्सएफएस के साथ डेटा हानि की रिपोर्ट मिली। मुझे यकीन नहीं है कि यह अभी भी एक समस्या है या अगर यह कभी था, लेकिन इसने मुझे स्पष्ट रूप से परेशान कर दिया। Ext4 उबंटू में डिफ़ॉल्ट fs है क्योंकि यह XFS पर आसानी से जीत गया।

इसलिए, टायलर के सुझाव के अलावा जो प्रबंधन के दृष्टिकोण से मदद करेगा, मेरा सुझाव है कि आप ext4 में अपग्रेड कर सकते हैं। Ext4 के साथ प्रति निर्देशिका सीमा 64000 प्रविष्टियाँ हैं

एक और लाभ यह है कि fsck का समय काफी तेज है। मैंने कभी भी भ्रष्टाचार को लेकर कोई मुद्दा नहीं रखा।

Ext4 के बारे में अच्छी बात यह है कि आप बाहर की कोशिश करने के लिए ext4 वॉल्यूम को ext4 पर माउंट कर सकते हैं। देखें: ext3 से ext4 फाइलसिस्टम में एक लाइव सिस्टम माइग्रेट करना

उस लिंक से एक उद्धरण:

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

तो, आगे बढ़ो और इसे आज़माएं। आप पहले बैकअप का सुझाव दें।

Answer 7

ऐसा करने के कुछ परिणाम होने जा रहे हैं। प्राथमिक एक IO पढ़ा / लिखा जा रहा है। इसके अलावा, यह उस प्रकार के डेटा (उस पैमाने पर) से निपटने का एक बहुत ही डरावना तरीका है।

Comments

एक ही निर्देशिका में सभी फ़ाइलों को रखने के लिए एक कम डराने का तरीका होगा?

— टी। ब्रायन जोन्स

मुझे लगता है कि यह डरावना की आपकी परिभाषा पर निर्भर करता है। यह तथ्य कि आप इन सभी को समन्वित करने के लिए DB का उपयोग कर रहे हैं, कम डरावना लगता है। मैं निश्चित रूप से कोशिश करूंगा और कम से कम कुछ विकल्प के लिए निर्देशिका संरचना को कम करूंगा? Ie, तिथि के आधार पर, उन्हें समूहीकृत करना, आदि

— 20

वे उपयोगकर्ता द्वारा समूहीकृत हैं। वेब एप्लिकेशन के लिए इस तरह के संरचित किए गए बड़े फाइल सिस्टम को देखने के अन्य तरीकों का कोई उदाहरण?

— टी। ब्रायन जोन्स

मैंने जिन प्रणालियों का सामना किया है उनमें से अधिकांश दुर्भाग्य से EXT3 का उपयोग नहीं कर रहे हैं। मुझे लगता है कि यह आपकी पहली बाधा हो सकती है।

— सार्वजनिक उपक्रम

गलत। एक बार जब एक फ़ाइल खोली जाती है और एक खुला हैंडल प्राप्त होता है तो I / O से फ़ाइल प्रभावित नहीं होती है। हालाँकि, फ़ाइल खुले समय IS प्रभावित है।

— मैट

Answer 8

अतीत में मैंने एक्सएफएस का उपयोग सफलता के साथ एक्सटी 3 की सीमाओं के आसपास करने के लिए किया है।

फ़ाइल सिस्टम सामग्री की पहली सूची में कुछ समय लगेगा जब तक कि सिस्टम ने सभी निर्देशिका / फ़ाइल जानकारी को नहीं पढ़ा है। अनुपूरक संचालन अधिक तेज़ होगा क्योंकि कर्नेल में अब कैश की गई जानकारी है।

मैंने देखा है कि कैश को सक्रिय रखने के लिए नियमित रूप से क्रोन में 'खोज / somepath 2> & 1> / dev / null' को चलाया जाता है, जिसके परिणामस्वरूप बेहतर प्रदर्शन होता है।

Answer 9

मेरे कुछ सवाल हैं और कुछ संभावित अड़चनें हैं।

पहला, क्या यह एक CentOS 5 या 6 प्रणाली है? क्योंकि 6 में, हमारे पास एक अविश्वसनीय उपकरण है जिसे ब्लक्ट्रेस कहा जाता है जो इस तरह की स्थितियों में प्रभाव को मापने के लिए आदर्श है।

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

हम आउटपुट को btt के साथ पार्स कर सकते हैं और पा सकते हैं कि अड़चन कहां है, एप्लिकेशन, फाइलसिस्टम, शेड्यूलर, स्टोरेज - जिस घटक पर IO अधिकतर समय बिता रहा है।

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

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

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

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

Answer 10

यह CentOS 5 पर एक विकल्प नहीं है, और यह सुनिश्चित नहीं है कि यह CentOS 6 पर एक विकल्प है, लेकिन मुझे यह महसूस होता है कि B ट्री या B * ट्री आधारित समाधान यानी BTRFS संगत प्रदान करेगा, यदि आपके विशेष रूप से बेहतर प्रदर्शन नहीं है परिदृश्य, यदि केवल एक व्यक्ति के कीमती डेटा के साथ एक स्पष्ट विवेक के साथ इसे सौंप सकता है (मैं अभी भी नहीं करूंगा)।

लेकिन अगर आप बर्दाश्त कर सकते हैं, तो आप इसका परीक्षण कर सकते हैं।