डिस्क से अच्छा समवर्ती पढ़ने प्रदर्शन कैसे प्राप्त करें

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

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

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

यदि हम धागे में से किसी एक को अक्षम करते हैं और अस्थायी रूप से एक थ्रेड के प्रदर्शन को देखते हैं तो हमें बहुत बेहतर बैंडविड्थ (~ 45 एमआईबी/सेकंड इस मशीन के लिए) मिलता है। तो स्पष्ट रूप से खराब दो-थ्रेड प्रदर्शन ओएस डिस्क शेड्यूलर का एक आर्टेफैक्ट है।

Is there anything we can do to improve the concurrent thread read performance? Perhaps by using different APIs or by tweaking the OS disk scheduler parameters in some way.

कुछ विवरण:

फाइलें 2 जीबीबी रैम वाली मशीन पर 2 जीबीबी के क्रम में हैं। इस प्रश्न के प्रयोजन के लिए हम उन्हें कैश किए जाने और पूरी तरह से अपरिवर्तित नहीं होने पर विचार करते हैं। हमने डीफ्रैग टूल्स का इस्तेमाल किया है और यह सुनिश्चित करने के लिए रीबूट किया गया है कि यह मामला है।

हम इन फ़ाइलों को पढ़ने के लिए कोई विशेष एपीआई का उपयोग नहीं कर रहे हैं। व्यवहार विभिन्न बोग-मानक एपीआई जैसे Win32 के CreateFile, C's fopen, C ++ के std :: ifstream, Java की FileInputStream, आदि में दोहराया जा सकता है।

लूप बनाने में प्रत्येक थ्रेड स्पिन पढ़ने के फ़ंक्शन पर कॉल करता है। हमने 1KiB से 128MiB के बीच मानों से प्रत्येक पुनरावृत्ति API से अनुरोध किए गए बाइट्स की संख्या को अलग किया है। इस पर ध्यान देने से कोई प्रभाव नहीं पड़ा है, इसलिए प्रत्येक डिस्क की तलाश के बाद ओएस शारीरिक रूप से पढ़ने की मात्रा को स्पष्ट रूप से पढ़ता है। यह वही है जो उम्मीद की जानी चाहिए।

विंडोज 2000, विंडोज एक्सपी (32-बिट और 64-बिट), विंडोज सर्वर 2003, और हार्डवेयर RAID5 के साथ और बिना भी एक-थ्रेड और दो-थ्रेड प्रदर्शन के बीच नाटकीय अंतर दोहराया जा सकता है।

0
ro fr bn

6 उत्तर

क्या आप विंडोज के तहत IOCompletionPorts का उपयोग करते हैं? सी ++ के माध्यम से विंडोज़ इस विषय पर गहन अध्याय है और भाग्य के रूप में यह होगा, यह एमएसडीएन पर भी उपलब्ध है

0
जोड़ा

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

विंडोज के लिए हमारा समाधान FILE_FLAG_NO_BUFFERING ध्वज को CreateFile पर पास करना है और प्रत्येक कॉल में ReadFile को पढ़ने के लिए बड़े (~ 16MiB) का उपयोग करना है। यह कई कारणों से उपमहाद्वीप है:

  • इस तरह पढ़ने के दौरान फ़ाइलों को कैश नहीं किया जाता है, इसलिए सामान्य रूप से कैशिंग को प्रदान करने वाले कोई भी लाभ नहीं हैं।
  • इस ध्वज के साथ काम करते समय बाधाएं सामान्य पढ़ने (पृष्ठ सीमाओं को पढ़ने वाले बफर के संरेखण) से अधिक जटिल होती हैं।

(अंतिम टिप्पणी के रूप में। क्या यह समझाता है कि विंडोज के तहत स्वैपिंग इतनी नरक क्यों है? आईई, विंडोज़ किसी भी दक्षता के साथ कई फाइलों में आईओ करने में असमर्थ है, इसलिए अन्य सभी आईओ संचालनों को स्वैप करने के दौरान असमान रूप से धीमी गति से मजबूर होना पड़ता है।)


विल डीन के लिए कुछ और विवरण जोड़ने के लिए संपादित करें:

बेशक इन विभिन्न हार्डवेयर विन्यासों में कच्चे आंकड़े बदल गए (कभी-कभी काफी)। समस्या हालांकि प्रदर्शन में लगातार गिरावट है कि केवल एक थ्रेड से दो धागे पर जाने पर विंडोज़ पीड़ित होती है। परीक्षण की गई मशीनों का सारांश यहां दिया गया है:

  • विंडोज 2000, विंडोज एक्सपी (32-बिट), और विंडोज एक्सपी (64-बिट) एकल ड्राइव के साथ चल रहे विभिन्न युग के कई डेल वर्कस्टेशन (इंटेल ज़ीऑन)।
  • RAID 1 + 0 के साथ Windows Server 2003 (64-बिट) चल रहा एक डेल 1 यू सर्वर (इंटेल ज़ीऑन)।
  • विंडोज एक्सपी (64-बिट), और विंडोज सर्वर 2003, और हार्डवेयर RAID 5 के साथ एक एचपी वर्कस्टेशन (एएमडी ओपर्टन)।
  • मेरा घर अनबैंडेड पीसी (एएमडी एथलॉन 64) विंडोज एक्सपी (32-बिट), फ्रीबीएसडी (64-बिट), और सिंगल ड्राइव के साथ लिनक्स (64-बिट) चला रहा है।
  • मेरा घर मैकबुक (इंटेल कोर 1) मैक ओएस एक्स, एकल सैटा ड्राइव चला रहा है।
  • मेरा घर कुल्लू पीसी चल रहा है लिनक्स। अन्य प्रणालियों की तुलना में बेहद कमजोर है लेकिन मैंने दिखाया कि बहु-थ्रेडेड डिस्क पढ़ने पर भी यह मशीन RAID5 के साथ एक विंडोज सर्वर को बेहतर प्रदर्शन कर सकती है।

इन सभी प्रणालियों पर सीपीयू उपयोग परीक्षण के दौरान बहुत कम था और एंटी-वायरस अक्षम था।

मैं पहले उल्लेख करना भूल गया था लेकिन हमने सामान्य कोड 32 <�कोड> CreateFile API को FILE_FLAG_SEQUENTIAL_SCAN ध्वज सेट के साथ भी आजमाया। इस झंडे ने समस्या को ठीक नहीं किया।

0
जोड़ा
माइक्रोसॉफ्ट में आपका स्वागत है
जोड़ा लेखक v.oddou, स्रोत

यह थोड़ा अजीब लगता है कि आप विंडोज संस्करणों की एक विस्तृत श्रृंखला में एक अंतर और एक ड्राइव और हार्डवेयर RAID-5 के बीच कुछ भी नहीं देखते हैं।

यह केवल 'आंत महसूस' है, लेकिन इससे मुझे संदेह होता है कि यह वास्तव में एक साधारण समस्या है। ओएस एक्स और RAID5 के अलावा, यह सब एक ही मशीन पर कोशिश की गई थी - क्या आपने दूसरी मशीन की कोशिश की है? क्या इस सीपीयू का उपयोग मूल रूप से इस परीक्षण के दौरान शून्य है?

आप क्या लिख ​​सकते हैं सबसे छोटा ऐप क्या है जो इस समस्या को प्रदर्शित करता है? - मुझे इसे आजमाने की इच्छा होगी।

0
जोड़ा
सिंगल ड्राइव बनाम RAID5 के अनुसार: यदि दो बड़ी पर्याप्त फ़ाइलों से अनुक्रमिक डेटा पढ़ना है, तो आप सभी डिस्क सिर आगे और पीछे की ओर से नहीं बच सकते हैं; पट्टी का आकार आमतौर पर 16-128kiB होता है, इसलिए डेटा के 1 एमआईबी पढ़ने के लिए, आपको वहां खोजने के लिए सभी (या अधिकतर) सिर की आवश्यकता होती है।
जोड़ा लेखक tzot, स्रोत

पॉल - अद्यतन देखा। बहुत ही रोचक।

यह Vista या Win2008 पर आज़माकर दिलचस्प होगा, क्योंकि कुछ परिस्थितियों में लोग इन पर कुछ महत्वपूर्ण I/O सुधारों की रिपोर्ट कर रहे हैं।

एक अलग एपीआई के बारे में मेरा एकमात्र सुझाव फाइलों को मैप करने की मेमोरी को आजमाएगा - क्या आपने कोशिश की है? दुर्भाग्यवश प्रति फ़ाइल 2 जीबी पर, आप 32-बिट मशीन पर कई सारी फाइलों को मैप करने में सक्षम नहीं होंगे, जिसका अर्थ यह है कि यह उतना छोटा नहीं है जितना हो सकता है।

0
जोड़ा
खिड़कियों पर कुछ काम करने के लिए इस तरह विस्तारित होने के लिए, मैं बस अपनी प्रक्रिया को लिनक्स में ले जाने की वकालत करता हूं। प्रत्येक समाधान की लागत क्या है? ईमानदारी से ...
जोड़ा लेखक v.oddou, स्रोत

मैं मेमोरी थ्रेड सुरक्षित लॉक में कुछ प्रकार का निर्माण करूंगा। प्रत्येक थ्रेड लॉक पर तब तक इंतजार कर सकता था जब तक कि यह मुफ़्त न हो। जब ताला मुक्त हो जाता है, तो लॉक लें और परिभाषित लंबाई या डेटा की परिभाषित मात्रा के लिए फ़ाइल को पढ़ें, फिर किसी भी अन्य प्रतीक्षा धागे के लिए लॉक जारी करें।

0
जोड़ा

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

if THREAD A is reading from disk then wait for THREAD A to stop reading or wait for X ms
Read for X ms (or Y MB)
Stop reading and check status of thread A again  

आप स्थिति जांच के लिए सेमफोर का उपयोग कर सकते हैं या आप वास्तविक डिस्क कतार की स्थिति प्राप्त करने के लिए परफॉर्म काउंटर का उपयोग कर सकते हैं। एक्स और/या वाई के मानों को वास्तविक ट्रांफर दरों की जांच करके स्वचालित रूप से संशोधित किया जा सकता है और धीरे-धीरे उन्हें संशोधित किया जा सकता है, इस प्रकार जब वे विभिन्न मशीनों और/या ओएस पर चलते हैं तो थ्रूपुट को अधिकतम करते हैं। आप पाते हैं कि कैश, मेमोरी या RAID स्तर उन्हें किसी अन्य तरीके से प्रभावित करते हैं, लेकिन ऑटो-ट्यूनिंग के साथ आप हमेशा हर परिदृश्य में सर्वश्रेष्ठ प्रदर्शन प्राप्त करेंगे।

0
जोड़ा