2010-12-05 7 views
5

संदर्भ हमारे पास एक होमग्राउन फाइल सिस्टम-बैक कैशिंग लाइब्रेरी है। बड़ी संख्या में प्रविष्टियों (उदाहरण के लिए 100,000) के कारण वर्तमान में हमारे पास एक स्थापना के साथ प्रदर्शन समस्याएं हैं। समस्या: हम सभी fs प्रविष्टियों को एक "कैश निर्देशिका" में संग्रहीत करते हैं। बहुत बड़ी निर्देशिका खराब प्रदर्शन करते हैं।एनटीएफएस निर्देशिका में 100 के प्रविष्टियां हैं। 100 उपनिर्देशिकाओं में फैले हुए प्रदर्शन में कितना प्रदर्शन बढ़ता है?

हम उन प्रविष्टियों को उपनिर्देशिकाओं पर फैलाने की सोच रहे हैं - जैसे कि गिट करता है, उदा। ~ 1,000 प्रविष्टियों के साथ 100 उपनिर्देशिकाएं।

सवाल

मैं समझता हूँ कि छोटे निर्देशिका आकार फाइल सिस्टम का उपयोग के साथ मदद मिलेगी।

लेकिन "सभी निर्देशिकाओं में फैल जाएगा" सभी प्रविष्टियों को पार करने की गति, उदा। सभी 100,000 प्रविष्टियों को समझा/पढ़ना? अर्थात। जब हम एफएस स्टोर से कैश को प्रारंभ/गर्म करते हैं, तो हमें सभी 100,000 प्रविष्टियों (और पुरानी प्रविष्टियों को हटाने) को 10+ मिनट लग सकते हैं।

"डेटा फैलाना" इस "ट्रैवर्सल टाइम" को कम करेगा। इसके अतिरिक्त यह "ट्रैवर्सल" वास्तव में पुरानी प्रविष्टियों को हटा सकता है (उदा। एन दिनों के बाद पुराना) क्या "डेटा फैलाना" हटाना समय सुधार जाएगा?

अतिरिक्त संदर्भ -NTFS -Windows परिवार ओएस (सर्वर 2003, 2008)

-Java J2ee आवेदन।

मैं/हम फाइल सिस्टम स्केलेबिलिटी मुद्दों पर किसी भी स्कूली शिक्षा की सराहना करेंगे।

अग्रिम धन्यवाद।

होगा

पी.एस. मुझे टिप्पणी करनी चाहिए कि मेरे पास यह परीक्षण करने के लिए उपकरण और क्षमता है, लेकिन मुझे लगा कि मैं सिद्धांत और अनुभव के लिए हाइव दिमाग चुनूंगा।

+2

क्या आपने फ़ाइल सिस्टम को ट्यून करने का प्रयास किया है?उदाहरण के लिए, लघु फ़ाइल नाम अक्षम करना? –

उत्तर

5

मुझे यह भी विश्वास था कि उपनिर्देशिकाओं में फ़ाइलों को फैलाने से गति-अप संचालन होगा।

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

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

नोट, कि पूर्ण गणना (दोनों मामलों में) 400K फ़ाइलों के लिए लगभग 3 मिनट लग गई। यह महत्वपूर्ण समय है, लेकिन उपनिर्देशिका इसे और भी खराब बनाती है।

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

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

3

आप स्टेट या कैश निर्देशिका सूची, और केवल कभी पूरा पथ से यह भीतर स्टेट और खुली फ़ाइलों की जरूरत कभी नहीं है, यह नहीं होना चाहिए वास्तव में बात (कम से कम 100k फ़ाइलों में नहीं स्तर) कितने फ़ाइलों में हैं निर्देशिका।

कई कैशिंग फ्रेमवर्क और फाइल सिस्टम-भारी स्टोरेज इंजन ऐसे परिदृश्यों में फ़ाइल नामों में पहले वर्ण के आधार पर उपनिर्देशिकाएं बनाएंगे, ताकि यदि आप अपने कैश में "abcdefgh.png" फ़ाइल संग्रहीत कर रहे हैं, तो यह " कैश/ए/बी/cdefgh.png "बस" कैश/abcdefgh.png "के बजाय। यह मानता है कि आपके फ़ाइल नामों के पहले दो अक्षरों का वितरण लगभग वर्ण स्थान पर लगभग समान है।

जैसा कि आपने बताया है, चूंकि निर्देशिका में सूचीबद्ध या ट्रैवर्स करने वाले आपके प्राथमिक कार्य में पुरानी फाइलों को हटाने में है, तो मैं अनुशंसा करता हूं कि आप दिनांक और/या फ़ाइल कैश किए गए समय के आधार पर निर्देशिकाएं बनाएं, यानी "कैश/2010 /12/04/22/abcdefgh.png "और, जहां भी आप कैश को अनुक्रमित करते हैं, फ़ाइल नाम और दिनांक (विशेष रूप से यदि यह डेटाबेस में है) द्वारा इसे अनुक्रमित करना सुनिश्चित करें ताकि आप इंडेक्स से तारीख तक आइटम को तुरंत हटा सकें और हटा दें संबंधित निर्देशिका।

0

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

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

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

0

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

+0

"एनटीएफएस" नहीं "एनएफएस"। फाइल सिस्टम स्थानीय है, दूरस्थ नहीं है। – user331465

+0

@ उपयोगकर्ता 331465, उत्कृष्ट बिंदु। इस मामले में मेरा सुझाव है कि आप अपने हार्डवेयर को देखें। आप जितनी तेजी से ड्राइव कर सकते हैं उतनी तेजी से जा सकते हैं। –

संबंधित मुद्दे