समय सीमा अनुसूचक: Difference between revisions

From Vigyanwiki
(Created page with "डेडलाइन शेड्यूलर Linux कर्नेल के लिए एक I/O शेड्यूलिंग|I/O शेड्यूलर है जि...")
 
No edit summary
Line 1: Line 1:
डेडलाइन शेड्यूलर Linux कर्नेल के लिए एक I/O शेड्यूलिंग|I/O शेड्यूलर है जिसे 2002 में [[Jens Axboe]] द्वारा लिखा गया था।
समय सीमा अनुसूचक लिनक्स कर्नेल के लिए एक I/O शेड्यूलिंग|I/O शेड्यूलर है जिसे 2002 में [[Jens Axboe|जेन्स एक्सबो]] द्वारा लिखा गया था।


== सिंहावलोकन ==
== अवलोकन ==
{{Confusing|section|reason=The queue system is not well explained. A schema would be welcome|date=March 2014}}
समय सीमा अनुसूचक का मुख्य लक्ष्य अनुरोध के लिए प्रारंभ सेवा समय की आश्वासन देना है।<ref name="kernel-doc">{{cite web |title=Deadline I/O scheduler tunables |author=Jens Axboe |work=Linux kernel documentation |url=https://www.kernel.org/doc/Documentation/block/deadline-iosched.txt |accessdate= 20 November 2011 |date= 11 November 2002}}</ref> अनुरोधों की अप्राप्ति को रोकने के लिए सभी I/O संचालन पर समय सीमा प्रयुक्त करके ऐसा करता है। यह क्रमबद्ध पंक्तियां (पढ़ने और लिखने दोनों) के अतिरिक्त दो समय सीमा [[कतार (डेटा संरचना)|पंक्तियां (डेटा संरचना)]] भी बनाए रखता है। समय सीमा पंक्तियां को मूल रूप से उनकी समय सीमा (समाप्ति समय) द्वारा क्रमबद्ध किया जाता है जबकि क्रमबद्ध पंक्तियां को सेक्टर संख्या द्वारा क्रमबद्ध किया जाता है।
समय सीमा अनुसूचक का मुख्य लक्ष्य अनुरोध के लिए प्रारंभ सेवा समय की गारंटी देना है।<ref name="kernel-doc">{{cite web |title=Deadline I/O scheduler tunables |author=Jens Axboe |work=Linux kernel documentation |url=https://www.kernel.org/doc/Documentation/block/deadline-iosched.txt |accessdate= 20 November 2011 |date= 11 November 2002}}</ref> अनुरोधों की भुखमरी को रोकने के लिए सभी I/O संचालन पर समय सीमा लागू करके ऐसा करता है। यह क्रमबद्ध कतारों (पढ़ने और लिखने दोनों) के अलावा दो समय सीमा [[कतार (डेटा संरचना)]] भी बनाए रखता है। समय सीमा कतारों को मूल रूप से उनकी समय सीमा (समाप्ति समय) द्वारा क्रमबद्ध किया जाता है, जबकि क्रमबद्ध कतारों को सेक्टर संख्या द्वारा क्रमबद्ध किया जाता है।


अगले अनुरोध को पूरा करने से पहले, समय सीमा अनुसूचक तय करता है कि किस कतार का उपयोग करना है। रीड क्यू को उच्च प्राथमिकता दी जाती है, क्योंकि [[ प्रक्रिया (कंप्यूटिंग) ]] आमतौर पर रीड ऑपरेशंस पर ब्लॉक हो जाती है। अगला, समय सीमा अनुसूचक जाँचता है कि क्या समय सीमा कतार में पहला अनुरोध समाप्त हो गया है। अन्यथा, अनुसूचक क्रमबद्ध कतार से अनुरोधों का एक बैच प्रस्तुत करता है। दोनों ही मामलों में, अनुसूचक क्रमबद्ध कतार में चुने गए अनुरोध के बाद अनुरोधों के एक बैच को भी प्रस्तुत करता है।
अगले अनुरोध को पूरा करने से पहले समय सीमा अनुसूचक तय करता है कि किस पंक्तियां का उपयोग करना है। रीड क्यू को उच्च प्राथमिकता दी जाती है क्योंकि [[ प्रक्रिया (कंप्यूटिंग) ]] सामान्यतः रीड ऑपरेशंस पर ब्लॉक हो जाती है। अगला समय सीमा अनुसूचक जाँचता है कि क्या समय सीमा पंक्तियां में पहला अनुरोध समाप्त हो गया है। अन्यथा अनुसूचक क्रमबद्ध पंक्तियां से अनुरोधों का एक बैच प्रस्तुत करता है। दोनों ही स्थिति में अनुसूचक क्रमबद्ध पंक्तियां में चुने गए अनुरोध के बाद अनुरोधों के एक बैच को भी प्रस्तुत करता है।


डिफ़ॉल्ट रूप से, रीड रिक्वेस्ट का एक्सपायरी टाइम 500 ms होता है, राइट रिक्वेस्ट 5 सेकंड में एक्सपायर होती है।
डिफ़ॉल्ट रूप से पढ़ने के अनुरोध का समाप्ति समय 500 ms होता है लिखने के अनुरोध से 5 सेकंड में समाप्त होती है।


अनुसूचक का एक प्रारंभिक संस्करण जेन्स एक्सबो द्वारा जनवरी 2002 में प्रकाशित किया गया था।<ref>{{cite web |author=Jens Axboe |url=https://lkml.org/lkml/2002/1/4/31 |title=[PATCH][RFT] simple deadline I/O scheduler |website=Linux Kernel Mailing List Archive |date=4 January 2002 |accessdate=6 July 2014}}</ref>
अनुसूचक का एक प्रारंभिक संस्करण जेन्स एक्सबो द्वारा जनवरी 2002 में प्रकाशित किया गया था।<ref>{{cite web |author=Jens Axboe |url=https://lkml.org/lkml/2002/1/4/31 |title=[PATCH][RFT] simple deadline I/O scheduler |website=Linux Kernel Mailing List Archive |date=4 January 2002 |accessdate=6 July 2014}}</ref>
मापन ने दिखाया है कि समय सीमा I/O अनुसूचक कुछ मल्टीथ्रेडेड वर्कलोड के लिए CFQ I/O अनुसूचक से बेहतर प्रदर्शन करता है।<ref>{{cite web|author=IBM |title=कर्नेल वर्चुअल मशीन (केवीएम) केवीएम के लिए सर्वोत्तम अभ्यास|url=https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbestpractices_pdf.pdf |archive-url=https://web.archive.org/web/20160513210216/http://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbestpractices_pdf.pdf |url-status=dead |archive-date=May 13, 2016 |website=IBM |date=12 September 2013 |accessdate=6 July 2014 }}</ref>


मापन ने दिखाया है कि समय सीमा I/O अनुसूचक कुछ मल्टीथ्रेडेड वर्कलोड के लिए सीएफक्यू I/O अनुसूचक से उत्तम प्रदर्शन करता है।<ref>{{cite web|author=IBM |title=कर्नेल वर्चुअल मशीन (केवीएम) केवीएम के लिए सर्वोत्तम अभ्यास|url=https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbestpractices_pdf.pdf |archive-url=https://web.archive.org/web/20160513210216/http://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbestpractices_pdf.pdf |url-status=dead |archive-date=May 13, 2016 |website=IBM |date=12 September 2013 |accessdate=6 July 2014 }}</ref>


== sysfs tunables ==
 
 
== एसआईएसएफएस ट्यूनेबल ==


=== फीफो_बैच (पूर्णांक) ===
=== फीफो_बैच (पूर्णांक) ===
बैचों की अवधारणा के माध्यम से डेडलाइन I/O ऑपरेशंस (IOPs) को निष्पादित करती है, जो बढ़ती हुई सेक्टर संख्या के संदर्भ में ऑपरेशंस के सेट हैं। यह ट्यून करने योग्य निर्धारित करता है कि अनुरोधों को डिस्क पर कतारबद्ध करने से पहले कितना बड़ा बैच होना चाहिए (वर्तमान में निर्मित बैच की समाप्ति को छोड़कर)। छोटे बैच यह सुनिश्चित करके [[ विलंबता (इंजीनियरिंग) ]] को कम कर सकते हैं कि नए अनुरोधों को जल्द ही निष्पादित किया जाता है (बजाय संभवतः अधिक अनुरोधों के आने की प्रतीक्षा करने के बजाय), लेकिन ड्राइव हेड्स के समग्र संचलन को बढ़ाकर समग्र थ्रूपुट को कम कर सकते हैं (चूंकि अनुक्रमण एक बैच के भीतर होता है और नहीं उन दोनों के बीच)। इसके अतिरिक्त, यदि IOP की संख्या काफी अधिक है तो बैचों को वैसे भी समय पर निष्पादित किया जाएगा।
बैचों की अवधारणा के माध्यम से डेडलाइन I/O ऑपरेशंस (आईओपी) को निष्पादित करती है जो बढ़ती हुई सेक्टर संख्या के संदर्भ में ऑपरेशंस के सेट हैं। यह ट्यून करने योग्य निर्धारित करता है कि अनुरोधों को डिस्क पर कतारबद्ध करने से पहले कितना बड़ा बैच होना चाहिए (वर्तमान में निर्मित बैच की समाप्ति को छोड़कर) छोटे बैच यह सुनिश्चित करके [[ विलंबता (इंजीनियरिंग) ]] को कम कर सकते हैं कि नए अनुरोधों को जल्द ही निष्पादित किया जाता है (इसके अतिरिक्त संभवतः अधिक अनुरोधों के आने की प्रतीक्षा करने के अतिरिक्त ), किन्तु ड्राइव हेड्स के समग्र संचलन को बढ़ाकर समग्र थ्रूपुट को कम कर सकते हैं (चूंकि अनुक्रमण एक बैच के अंदर होता है और नहीं उन दोनों के बीच) इसके अतिरिक्त, यदि आईओपी की संख्या बहुत अधिक है तो बैचों को वैसे भी समय पर निष्पादित किया जाएगा।


=== read_expire (पूर्णांक) ===
=== पढ़ने के अनुरोध का समाप्ति (पूर्णांक) ===
'रीड_एक्सपायर' समय मिलीसेकंड में अधिकतम समय है जिसके बाद रीड को 'समाप्त' माना जाता है। इसे दूध के कार्टन पर समाप्ति तिथि की तरह अधिक समझें। समाप्ति तिथि से पहले दूध का सबसे अच्छा उपयोग किया जाता है। समय सीमा अनुसूचक के साथ ही। यह सुनिश्चित करने का प्रयास नहीं करेगा कि सभी आईओ इसकी समाप्ति तिथि से पहले जारी किए गए हैं। हालाँकि, यदि IO की समय सीमा समाप्त हो गई है, तो इसे प्राथमिकता में टक्कर मिलती है…। चेतावनियों के साथ।
'रीड_एक्सपायर' समय मिलीसेकंड में अधिकतम समय है जिसके बाद रीड को 'समाप्त' माना जाता है। इसे दूध के कार्टन पर समाप्ति तिथि की तरह अधिक समझें समाप्ति तिथि से पहले दूध का सबसे अच्छा उपयोग किया जाता है। समय सीमा अनुसूचक के साथ ही यह सुनिश्चित करने का प्रयास नहीं करेगा कि सभी आईओ इसकी समाप्ति तिथि से पहले जारी किए गए हैं। चूँकि  यदि IO की समाप्ति समाप्त हो गई है तो इसे कैविएट्स के साथ प्राथमिकता में उभार मिलती है।


पढ़ने की समाप्ति कतार केवल तभी चेक की जाती है जब समय सीमा अनुसूचक रीड कतार का पुनर्मूल्यांकन करता है। पढ़ने के लिए इसका मतलब है कि स्ट्रीमिंग आईओ के मामले के अलावा हर बार एक क्रमबद्ध रीड भेजा जाता है। जबकि शेड्यूलर रीड क्यू से io स्ट्रीमिंग कर रहा है, रीड एक्सपायर का मूल्यांकन नहीं किया गया है। रीड क्यू का पुनर्मूल्यांकन करते समय, तर्क है
पढ़ने की समाप्ति पंक्तियां केवल तभी चेक की जाती है जब समय सीमा अनुसूचक रीड पंक्तियां का पुनर्मूल्यांकन करता है। पढ़ने के लिए इसका अर्थ है कि स्ट्रीमिंग आईओ के स्थिति के अतिरिक्त हर बार एक क्रमबद्ध रीड भेजा जाता है। जबकि शेड्यूलर रीड क्यू से io स्ट्रीमिंग कर रहा है रीड एक्सपायर का मूल्यांकन नहीं किया गया है। रीड क्यू का पुनर्मूल्यांकन करते समय तर्क है


एक्सपायर्ड रीड्स की जांच करें (FIFO [टाइम ऑर्डर्ड] क्यू के प्रमुख को देखें)
एक्सपायर्ड रीड्स की जांच करें (फीफो [टाइम ऑर्डर्ड] क्यू के प्रमुख को देखें) यह देखने के लिए जांचें कि क्या कैश्ड रीड सूचक वैध है (इसलिए स्ट्रीमिंग नहीं होने पर भी, कैश्ड सूचक को अभी भी प्राथमिकता दी जाती है, इसलिए सॉर्ट की गई पंक्तियां को एक स्वीप में टिप टू टेल ट्रैवर्स किया जाता है) सॉर्ट की गई पंक्तियां से पहला रीड चुनें (दूसरे स्वीप के लिए फिर से टिप पर प्रारंभ करें) यदि एक्सपायर्ड रीड्स हैं, तो पहले वाले को फीफो से हटा लिया जाता है। ध्यान दें कि यह एक्सपायर्ड रीड तब ​​रीड सॉर्ट ऑर्डरिंग के लिए नया नेक्सस है। इस समाप्त होने के बाद कैश्ड नेक्स्ट सूचक को सॉर्ट पंक्तियां से अगले io को इंगित करने के लिए सेट किया जाएगा…। ध्यान देने वाली बात यह है कि एक बार जब वे अपनी समाप्ति तिथि पार कर लेते हैं तो एल्गोरिथ्म केवल सभी समाप्त हो चुके io को निष्पादित नहीं करता है। यह समाप्त हो चुकी रीड क्यू को फिर से जाँचने से पहले 'राइट_स्टारवेड' सॉर्ट किए गए रीड्स को एक साथ बैच करके कुछ उचित प्रदर्शन को बनाए रखने की अनुमति देता है।
यह देखने के लिए जांचें कि क्या कैश्ड रीड पॉइंटर वैध है (इसलिए स्ट्रीमिंग नहीं होने पर भी, कैश्ड पॉइंटर को अभी भी प्राथमिकता दी जाती है, इसलिए सॉर्ट की गई कतार को एक स्वीप में टिप टू टेल ट्रैवर्स किया जाता है)
सॉर्ट की गई कतार से पहला रीड चुनें (दूसरे स्वीप के लिए फिर से टिप पर शुरू करें)
यदि एक्सपायर्ड रीड्स हैं, तो पहले वाले को फीफो से हटा लिया जाता है। ध्यान दें कि यह एक्सपायर्ड रीड तब ​​रीड सॉर्ट ऑर्डरिंग के लिए नया नेक्सस है। इस समाप्त होने के बाद कैश्ड नेक्स्ट पॉइंटर को सॉर्ट कतार से अगले io को इंगित करने के लिए सेट किया जाएगा…। ध्यान देने वाली बात यह है कि एक बार जब वे अपनी समाप्ति तिथि पार कर लेते हैं, तो एल्गोरिथ्म केवल सभी समाप्त हो चुके io को निष्पादित नहीं करता है। यह समाप्त हो चुकी रीड क्यू को फिर से जाँचने से पहले 'राइट_स्टारवेड' सॉर्ट किए गए रीड्स को एक साथ बैच करके कुछ उचित प्रदर्शन को बनाए रखने की अनुमति देता है।


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


=== राइट_एक्सपायर (पूर्णांक) ===
=== राइट_एक्सपायर (पूर्णांक) ===


Read_expire के समान लेकिन लिखने के संचालन के लिए (रीड से अलग बैचों में समूहीकृत)।
राइट_एक्सपायर के समान किन्तु लिखने के संचालन के लिए (रीड से अलग बैचों में समूहीकृत)।


=== लिखता_भूखा (पूर्णांक) ===
=== लिखता_अप्राप्ति (पूर्णांक) ===


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


=== front_merges (बूल पूर्णांक) ===
=== फ्रंट मेर्जेस  (बूल पूर्णांक) ===


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


जिस तरह से फाइलें आमतौर पर रखी जाती हैं, उसके कारण बैक मर्ज फ्रंट मर्ज की तुलना में बहुत अधिक सामान्य हैं। कुछ कार्यभार के लिए, आप यह भी जान सकते हैं कि किसी भी समय मर्ज अनुरोधों को आगे बढ़ाने का प्रयास करना समय की बर्बादी है। Front_merges को 0 पर सेट करने से यह कार्यक्षमता अक्षम हो जाती है। कैश्ड last_merge संकेत के कारण फ्रंट मर्ज अभी भी हो सकता है, लेकिन चूंकि यह मूल रूप से शून्य लागत पर आता है, यह अभी भी किया जाता है। जब I/O शेड्यूलर मर्जिंग फ़ंक्शन को कॉल किया जाता है, तो यह बूलियन केवल फ्रंट सेक्टर लुकअप को अक्षम कर देता है। डिस्क मर्ज योग प्रति-ब्लॉक डिवाइस / proc / डिस्कस्टैट्स में रिकॉर्ड किए जाते हैं।<ref name="kernel-doc"/>
जिस तरह से फाइलें सामान्यतः रखी जाती हैं उसके कारण बैक मर्ज फ्रंट मर्ज की तुलना में बहुत अधिक सामान्य हैं। कुछ कार्यभार के लिए आप यह भी जान सकते हैं कि किसी भी समय मर्ज अनुरोधों को आगे बढ़ाने का प्रयास करना समय की अपशिष्ट है। फ्रंट मेर्जेस  को 0 पर सेट करने से यह कार्यक्षमता अक्षम हो जाती है। कैश्ड लास्ट मर्ज संकेत के कारण फ्रंट मर्ज अभी भी हो सकता है, किन्तु चूंकि यह मूल रूप से शून्य निवेश  पर आता है, यह अभी भी किया जाता है। जब I/O शेड्यूलर मर्जिंग कार्य को कॉल किया जाता है तो यह बूलियन केवल फ्रंट सेक्टर लुकअप को अक्षम कर देता है। डिस्क मर्ज योग प्रति-ब्लॉक उपकरण / प्रोक/ डिस्कस्टैट्स में सूचित किए जाते हैं।<ref name="kernel-doc"/>




Revision as of 13:11, 14 June 2023

समय सीमा अनुसूचक लिनक्स कर्नेल के लिए एक I/O शेड्यूलिंग|I/O शेड्यूलर है जिसे 2002 में जेन्स एक्सबो द्वारा लिखा गया था।

अवलोकन

समय सीमा अनुसूचक का मुख्य लक्ष्य अनुरोध के लिए प्रारंभ सेवा समय की आश्वासन देना है।[1] अनुरोधों की अप्राप्ति को रोकने के लिए सभी I/O संचालन पर समय सीमा प्रयुक्त करके ऐसा करता है। यह क्रमबद्ध पंक्तियां (पढ़ने और लिखने दोनों) के अतिरिक्त दो समय सीमा पंक्तियां (डेटा संरचना) भी बनाए रखता है। समय सीमा पंक्तियां को मूल रूप से उनकी समय सीमा (समाप्ति समय) द्वारा क्रमबद्ध किया जाता है जबकि क्रमबद्ध पंक्तियां को सेक्टर संख्या द्वारा क्रमबद्ध किया जाता है।

अगले अनुरोध को पूरा करने से पहले समय सीमा अनुसूचक तय करता है कि किस पंक्तियां का उपयोग करना है। रीड क्यू को उच्च प्राथमिकता दी जाती है क्योंकि प्रक्रिया (कंप्यूटिंग) सामान्यतः रीड ऑपरेशंस पर ब्लॉक हो जाती है। अगला समय सीमा अनुसूचक जाँचता है कि क्या समय सीमा पंक्तियां में पहला अनुरोध समाप्त हो गया है। अन्यथा अनुसूचक क्रमबद्ध पंक्तियां से अनुरोधों का एक बैच प्रस्तुत करता है। दोनों ही स्थिति में अनुसूचक क्रमबद्ध पंक्तियां में चुने गए अनुरोध के बाद अनुरोधों के एक बैच को भी प्रस्तुत करता है।

डिफ़ॉल्ट रूप से पढ़ने के अनुरोध का समाप्ति समय 500 ms होता है लिखने के अनुरोध से 5 सेकंड में समाप्त होती है।

अनुसूचक का एक प्रारंभिक संस्करण जेन्स एक्सबो द्वारा जनवरी 2002 में प्रकाशित किया गया था।[2]

मापन ने दिखाया है कि समय सीमा I/O अनुसूचक कुछ मल्टीथ्रेडेड वर्कलोड के लिए सीएफक्यू I/O अनुसूचक से उत्तम प्रदर्शन करता है।[3]


एसआईएसएफएस ट्यूनेबल

फीफो_बैच (पूर्णांक)

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

पढ़ने के अनुरोध का समाप्ति (पूर्णांक)

'रीड_एक्सपायर' समय मिलीसेकंड में अधिकतम समय है जिसके बाद रीड को 'समाप्त' माना जाता है। इसे दूध के कार्टन पर समाप्ति तिथि की तरह अधिक समझें समाप्ति तिथि से पहले दूध का सबसे अच्छा उपयोग किया जाता है। समय सीमा अनुसूचक के साथ ही यह सुनिश्चित करने का प्रयास नहीं करेगा कि सभी आईओ इसकी समाप्ति तिथि से पहले जारी किए गए हैं। चूँकि यदि IO की समाप्ति समाप्त हो गई है तो इसे कैविएट्स के साथ प्राथमिकता में उभार मिलती है।

पढ़ने की समाप्ति पंक्तियां केवल तभी चेक की जाती है जब समय सीमा अनुसूचक रीड पंक्तियां का पुनर्मूल्यांकन करता है। पढ़ने के लिए इसका अर्थ है कि स्ट्रीमिंग आईओ के स्थिति के अतिरिक्त हर बार एक क्रमबद्ध रीड भेजा जाता है। जबकि शेड्यूलर रीड क्यू से io स्ट्रीमिंग कर रहा है रीड एक्सपायर का मूल्यांकन नहीं किया गया है। रीड क्यू का पुनर्मूल्यांकन करते समय तर्क है

एक्सपायर्ड रीड्स की जांच करें (फीफो [टाइम ऑर्डर्ड] क्यू के प्रमुख को देखें) यह देखने के लिए जांचें कि क्या कैश्ड रीड सूचक वैध है (इसलिए स्ट्रीमिंग नहीं होने पर भी, कैश्ड सूचक को अभी भी प्राथमिकता दी जाती है, इसलिए सॉर्ट की गई पंक्तियां को एक स्वीप में टिप टू टेल ट्रैवर्स किया जाता है) सॉर्ट की गई पंक्तियां से पहला रीड चुनें (दूसरे स्वीप के लिए फिर से टिप पर प्रारंभ करें) यदि एक्सपायर्ड रीड्स हैं, तो पहले वाले को फीफो से हटा लिया जाता है। ध्यान दें कि यह एक्सपायर्ड रीड तब ​​रीड सॉर्ट ऑर्डरिंग के लिए नया नेक्सस है। इस समाप्त होने के बाद कैश्ड नेक्स्ट सूचक को सॉर्ट पंक्तियां से अगले io को इंगित करने के लिए सेट किया जाएगा…। ध्यान देने वाली बात यह है कि एक बार जब वे अपनी समाप्ति तिथि पार कर लेते हैं तो एल्गोरिथ्म केवल सभी समाप्त हो चुके io को निष्पादित नहीं करता है। यह समाप्त हो चुकी रीड क्यू को फिर से जाँचने से पहले 'राइट_स्टारवेड' सॉर्ट किए गए रीड्स को एक साथ बैच करके कुछ उचित प्रदर्शन को बनाए रखने की अनुमति देता है।

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

राइट_एक्सपायर (पूर्णांक)

राइट_एक्सपायर के समान किन्तु लिखने के संचालन के लिए (रीड से अलग बैचों में समूहीकृत)।

लिखता_अप्राप्ति (पूर्णांक)

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

फ्रंट मेर्जेस (बूल पूर्णांक)

एक फ्रंट मर्ज एक ऑपरेशन है जहां I/O अनुसूचक, छोटे अनुरोधों को कम (बड़े) संचालन में संघनित (या विलय) करने की मांग कर रहा है एक नया ऑपरेशन करेगा फिर सक्रिय बैच की जांच करेगा और संचालन का पता लगाने का प्रयास करेगा जहां प्रारंभिक क्षेत्र है एक ही या किसी अन्य ऑपरेशन के प्रारंभिक सेक्टर के तुरंत बाद एक बैक मर्ज विपरीत है जहां सक्रिय बैच में समाप्त होने वाले क्षेत्रों को उन क्षेत्रों के लिए खोजा जाता है जो या तो समान हैं या वर्तमान संचालन के प्रारंभिक क्षेत्रों के तुरंत बाद हैं। मर्ज करने से संचालन वर्तमान बैच से सक्रिय बैच में बदल जाता है थ्रूपुट बढ़ाने के लिए निष्पक्षता कम हो जाती है।

जिस तरह से फाइलें सामान्यतः रखी जाती हैं उसके कारण बैक मर्ज फ्रंट मर्ज की तुलना में बहुत अधिक सामान्य हैं। कुछ कार्यभार के लिए आप यह भी जान सकते हैं कि किसी भी समय मर्ज अनुरोधों को आगे बढ़ाने का प्रयास करना समय की अपशिष्ट है। फ्रंट मेर्जेस को 0 पर सेट करने से यह कार्यक्षमता अक्षम हो जाती है। कैश्ड लास्ट मर्ज संकेत के कारण फ्रंट मर्ज अभी भी हो सकता है, किन्तु चूंकि यह मूल रूप से शून्य निवेश पर आता है, यह अभी भी किया जाता है। जब I/O शेड्यूलर मर्जिंग कार्य को कॉल किया जाता है तो यह बूलियन केवल फ्रंट सेक्टर लुकअप को अक्षम कर देता है। डिस्क मर्ज योग प्रति-ब्लॉक उपकरण / प्रोक/ डिस्कस्टैट्स में सूचित किए जाते हैं।[1]


अन्य I/O अनुसूचक

संदर्भ

  1. ↑ 1.0 1.1 Jens Axboe (11 November 2002). "Deadline I/O scheduler tunables". Linux kernel documentation. Retrieved 20 November 2011.
  2. ↑ Jens Axboe (4 January 2002). "[PATCH][RFT] simple deadline I/O scheduler". Linux Kernel Mailing List Archive. Retrieved 6 July 2014.
  3. ↑ IBM (12 September 2013). "कर्नेल वर्चुअल मशीन (केवीएम) केवीएम के लिए सर्वोत्तम अभ्यास" (PDF). IBM. Archived from the original (PDF) on May 13, 2016. Retrieved 6 July 2014.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=समय_सीमा_अनुसूचक&oldid=192299’