लाखों छोटी फाइलों के लिए फाइलसिस्टम


44

निम्नलिखित परिदृश्य में आप सबसे अच्छी गति के लिए कौन सा लिनक्स फाइल सिस्टम चुनेंगे :

  • सौ मिलियन फाइलें
  • ~ 2k फ़ाइल का आकार औसत पर
  • > 95% रीड एक्सेस
  • बहुत यादृच्छिक पहुँच
  • उच्च संगामिति (> 100 प्रक्रियाएं)

नोट: फ़ाइलों को बड़ी निर्देशिकाओं से बचने के लिए एक गहरी श्रेणीबद्ध पेड़ में संग्रहीत किया जाता है। प्रत्येक पत्ती निर्देशिका में लगभग एक हजार फाइलें होती हैं।

आप इसे कैसे बेंचमार्क करेंगे?


3
कुछ अतिरिक्त जानकारी की आवश्यकता है। उदाहरण के लिए, क्या आप सभी फ़ाइलों को एक फ्लैट निर्देशिका में, या नेस्टेड (सॉर्ट किए गए) निर्देशिकाओं में संग्रहीत कर रहे हैं? यह फ़ाइल एक्सेस समय पर एक नाटकीय प्रदर्शन प्रभाव डाल सकता है। "फ्लैट" व्यवस्था में 100,000,000 प्रविष्टियों के माध्यम से स्थानांतरण एफएस प्रकार की परवाह किए बिना महत्वपूर्ण ओवरहेड प्राप्त करेगा; सबसे अच्छा मामला, आप किसी प्रकार की ट्री खोज को देख रहे हैं, जिसे अभी भी आपकी फ़ाइल पर आने के लिए कई लुकअप की आवश्यकता है। यदि आप फ़ाइलों को उपनिर्देशिकाओं में विभाजित करते हैं, तो एक्सेस समय में काफी तेजी आएगी क्योंकि प्रत्येक स्तर पर खोज के लिए कम प्रविष्टियाँ हैं।
एवेरी पायने

क्या फ़ाइल को क्रमिक रूप से या समवर्ती रूप से एक्सेस किया गया है?
स्टीव श्नेप

जवाबों:


19

यहाँ कुछ प्रमुख linux FSes की तुलना बोनी ++ के साथ करने के कुछ परिणाम दिए गए हैं जिनका उपयोग आप एक प्रारंभिक बिंदु के रूप में कर सकते हैं।

यादृच्छिक चेष्टाओं के संदर्भ में रेसर जीतता है, EXT4 द्वारा पीछा किया जाता है, इसके बाद JFS का स्थान आता है। मुझे यकीन नहीं है कि यह निर्देशिका लुकअप के लिए बिल्कुल सहसंबद्ध होगा, लेकिन ऐसा लगता है कि यह एक संकेतक होगा। आपको इसके लिए विशेष रूप से अपने परीक्षण करने होंगे। EXT2 ने फ़ाइल निर्माण के समय के लिए पैंट को सब कुछ बंद कर दिया है, संभवतः इसकी कमी के कारण एक पत्रिका है, फिर भी EXT4 रेसर को छोड़कर सब कुछ धड़कता है जिसे आप हंस के वर्तमान स्थिति के कारण उपयोग नहीं करना चाहते हैं।

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

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


1
बोनी की ++ समस्या यह है कि यह और भी मोटे तौर पर मेरी उपयोग परिदृश्य परीक्षण नहीं होता है
लाभ

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

7
@AndrewCholakian लिंक अब मृत है।
डॉन स्कॉट

8

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

हंस रेज़र की स्थिति के रूप में, मैं इसे फ़ाइल सिस्टम के कोड या स्थिरता के साथ समस्या के रूप में नहीं देखता। Reiser4 यहां तक ​​कि DARPA और Linspire दोनों द्वारा प्रायोजित है, जबकि मैं सहमत हूं कि Reiser फ़ाइल सिस्टम का और अधिक विकास अनिर्धारित है, मैं यह नहीं कहता कि एक निर्णायक कारक होना चाहिए कि किसी को इसका उपयोग करना चाहिए या नहीं।


3
मैंने लंबे समय से ReiserFS का उपयोग किया है। वास्तव में, मैं अभी भी इसे एक पुराने जेंटू सर्वर पर उपयोग कर रहा हूं जिसे मैंने अभी तक पुनः इंस्टॉल नहीं किया है। यह इंस्टॉलेशन इस मई में 4 साल का है। मैं आपको बता सकता हूं कि यह काफी धीमा हो गया है। ReiserFS का उपयोग करके सभी फ़ाइल सिस्टम पर समय के साथ यह घटना हुई है, जो सभी मशीनों पर सक्रिय पठन + लेखन उपयोग में हैं, जिसमें ऐसी फाइल सिस्टम थे, कोई अपवाद नहीं है - इसलिए यदि आप इसे लंबे समय तक उपयोग करना चाहते हैं तो यह रखने के लिए कुछ है। दिमाग में। अब मैं इससे दूर हो गया हूं, बड़े फाइल सिस्टम के लिए एक्सएफएस का उपयोग कर रहा हूं।
मिहाई लिम्बायसन

3

मुझे पता है कि यह आपके सवाल का सीधा जवाब नहीं है, लेकिन इन मामलों में मुझे लगता है कि एक डेटाबेस इसे होस्ट करने के लिए अधिक उपयुक्त हो सकता है। छोटी फ़ाइलों को एक डेटाबेस तालिका में बाइनरी प्रारूप में संग्रहीत किया जा सकता है और wil पर पुनर्प्राप्त किया जा सकता है। सॉफ्टवेयर है कि इन फ़ाइलों का उपयोग कर रहा है, हालांकि यह समर्थन करने में सक्षम होना चाहिए ...


1
यदि एक पदानुक्रमित डेटाबेस नहीं है, तो फ़ाइल सिस्टम क्या है? आपके प्रस्ताव में अमूर्तता, जटिलता और सॉफ़्टवेयर की परतें शामिल हैं जो शायद वारंट नहीं हैं। इसके अलावा, सवाल के मालिक 'UNIX दर्शन' के साथ अपने कार्य को पूरा कर रहे हैं, जिस पर मुझे संदेह है कि आप एक विंडोज लड़के के अधिक नापसंद हैं?
स्टु थॉम्पसन

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

1
और लिनक्स पर एक फाइल सिस्टम को डीफ्रैग करने की तुलना में एक db फाइल को "क्लीन / वैक्यूम" करना ज्यादा आसान है। अधिकांश / सभी fs उस कार्यक्षमता को प्रदान नहीं करते हैं, यह कहते हुए कि यह आवश्यक नहीं है। ऊपर मिहाई की टिप्पणी को देखते हुए, आप देख सकते हैं कि यह कड़ाई से सच नहीं है।
ग्रिंगो सुवे

3

यूनिक्स StackExchange पर किसी ने एक बेंचमार्क बनाया (स्रोत के साथ) बस इस परिदृश्य का परीक्षण करने के लिए:

प्रश्न: बहुत सारी छोटी फाइलों (एचडीडी, एसएसडी नहीं) के भंडारण के लिए सबसे उच्च-प्रदर्शन लिनक्स फाइल सिस्टम क्या है?

सबसे अच्छा पढ़ा प्रदर्शन ReiserFS से आने लगता है।


Btrfs को हर चीज़ में बेहतर या तुलनीय परिणाम देखने को मिलते हैं लेकिन हटाते हैं। लेकिन, आप कितनी बार 300k फाइल डिलीट करते हैं? मुझे अतीत में rfs पसंद थे, लेकिन btrfs भविष्य के लिए बेहतर शर्त हो सकते हैं।
ग्रिंगो सुवे

3

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

इन आदेशों को चलाने से ext2 और भी तेज हो जाता है (भले ही इनमें से अधिकांश विकल्प क्रैश के बाद फाइल सिस्टम को अस्थिर कर देते हैं जब तक कि आप क्रैश से पहले सिंक नहीं चलाते)। इन कमांड्स का छोटी फ़ाइलों के साथ ext4 पर लगभग कोई प्रभाव नहीं पड़ता है।

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

1

मुझे लगता है कि ext3 (या ext4), शायद JFS अच्छा समाधान होगा। मैं ext4 और btrfs के साथ सावधान रहूंगा (फाइलसिस्टम ट्रिकी हैं - बैकअप के साथ तैयार रहें यदि आप नवीनतम, नवीनतम सामान का उपयोग करना चाहते हैं)।

वहाँ भी विभिन्न मापदंडों आप mkfs समय के दौरान अपने पसंद के हिसाब से फाइल सिस्टम ट्यून कर सकते हैं।

मैं निश्चित रूप से एक्सएफएस के खिलाफ सिफारिश करूंगा । इसलिए नहीं कि यह एक खराब फाइल सिस्टम है, बल्कि इस पर निर्माण / विलोपन एक महंगा ऑपरेशन है।


निर्देशिका खोजों के साथ समस्याओं से बचने के लिए, उदाहरण के लिए, एक बुद्धिमान नामकरण योजना का उपयोग करें:

<first letter of id>_<last letter of id>/<id>

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


1
पहले और आखिरी अक्षर का उपयोग करने का क्या फायदा है और न केवल पहले n अक्षर?
लाभ

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

1

सबसे एफएस एक चक्कर में 65K से अधिक फाइलों के साथ घुट जाएगा, मुझे लगता है कि अभी भी ext4 का सच है। रीज़र फ़ाइल सिस्टम में वह सीमा नहीं होती है (mp3.com पर लोगों ने यह सुनिश्चित करने के लिए भुगतान किया है)। किसी और चीज के बारे में निश्चित नहीं है, लेकिन यह उन उपयोग परिदृश्यों में से एक है, जिनके लिए ReiserFS बनाया गया था।


1
यह ReiserFS है, RieserFS नहीं
डैनियल रिकोस्की

इस सप्ताह के अंत में मैं ext4 पर एक dir था जिसमें 1000000 फाइलें थीं। जब तक आप ऐसा नहीं करते हैं lsया टैब-पूरा नहीं होता है तब तक यह तेजी से काम करता है। शायद सूचकांक के कारण।
ओले तांगे

ext4 में dir_index एक्सटेंशन है, जो एक डायरेक्टरी में कई फाइलों को गति देता है।
अल्फोंक्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.