समय सीमा अनुसूचक
डेडलाइन शेड्यूलर Linux कर्नेल के लिए एक I/O शेड्यूलिंग|I/O शेड्यूलर है जिसे 2002 में Jens Axboe द्वारा लिखा गया था।
सिंहावलोकन
 | This section may be confusing or unclear to readers. In particular, The queue system is not well explained. A schema would be welcome. (March 2014) (Learn how and when to remove this template message) |
समय सीमा अनुसूचक का मुख्य लक्ष्य अनुरोध के लिए प्रारंभ सेवा समय की गारंटी देना है।[1] अनुरोधों की भुखमरी को रोकने के लिए सभी I/O संचालन पर समय सीमा लागू करके ऐसा करता है। यह क्रमबद्ध कतारों (पढ़ने और लिखने दोनों) के अलावा दो समय सीमा कतार (डेटा संरचना) भी बनाए रखता है। समय सीमा कतारों को मूल रूप से उनकी समय सीमा (समाप्ति समय) द्वारा क्रमबद्ध किया जाता है, जबकि क्रमबद्ध कतारों को सेक्टर संख्या द्वारा क्रमबद्ध किया जाता है।
अगले अनुरोध को पूरा करने से पहले, समय सीमा अनुसूचक तय करता है कि किस कतार का उपयोग करना है। रीड क्यू को उच्च प्राथमिकता दी जाती है, क्योंकि प्रक्रिया (कंप्यूटिंग) आमतौर पर रीड ऑपरेशंस पर ब्लॉक हो जाती है। अगला, समय सीमा अनुसूचक जाँचता है कि क्या समय सीमा कतार में पहला अनुरोध समाप्त हो गया है। अन्यथा, अनुसूचक क्रमबद्ध कतार से अनुरोधों का एक बैच प्रस्तुत करता है। दोनों ही मामलों में, अनुसूचक क्रमबद्ध कतार में चुने गए अनुरोध के बाद अनुरोधों के एक बैच को भी प्रस्तुत करता है।
डिफ़ॉल्ट रूप से, रीड रिक्वेस्ट का एक्सपायरी टाइम 500 ms होता है, राइट रिक्वेस्ट 5 सेकंड में एक्सपायर होती है।
अनुसूचक का एक प्रारंभिक संस्करण जेन्स एक्सबो द्वारा जनवरी 2002 में प्रकाशित किया गया था।[2] मापन ने दिखाया है कि समय सीमा I/O अनुसूचक कुछ मल्टीथ्रेडेड वर्कलोड के लिए CFQ I/O अनुसूचक से बेहतर प्रदर्शन करता है।[3]
sysfs tunables
फीफो_बैच (पूर्णांक)
बैचों की अवधारणा के माध्यम से डेडलाइन I/O ऑपरेशंस (IOPs) को निष्पादित करती है, जो बढ़ती हुई सेक्टर संख्या के संदर्भ में ऑपरेशंस के सेट हैं। यह ट्यून करने योग्य निर्धारित करता है कि अनुरोधों को डिस्क पर कतारबद्ध करने से पहले कितना बड़ा बैच होना चाहिए (वर्तमान में निर्मित बैच की समाप्ति को छोड़कर)। छोटे बैच यह सुनिश्चित करके विलंबता (इंजीनियरिंग) को कम कर सकते हैं कि नए अनुरोधों को जल्द ही निष्पादित किया जाता है (बजाय संभवतः अधिक अनुरोधों के आने की प्रतीक्षा करने के बजाय), लेकिन ड्राइव हेड्स के समग्र संचलन को बढ़ाकर समग्र थ्रूपुट को कम कर सकते हैं (चूंकि अनुक्रमण एक बैच के भीतर होता है और नहीं उन दोनों के बीच)। इसके अतिरिक्त, यदि IOP की संख्या काफी अधिक है तो बैचों को वैसे भी समय पर निष्पादित किया जाएगा।
read_expire (पूर्णांक)
'रीड_एक्सपायर' समय मिलीसेकंड में अधिकतम समय है जिसके बाद रीड को 'समाप्त' माना जाता है। इसे दूध के कार्टन पर समाप्ति तिथि की तरह अधिक समझें। समाप्ति तिथि से पहले दूध का सबसे अच्छा उपयोग किया जाता है। समय सीमा अनुसूचक के साथ ही। यह सुनिश्चित करने का प्रयास नहीं करेगा कि सभी आईओ इसकी समाप्ति तिथि से पहले जारी किए गए हैं। हालाँकि, यदि IO की समय सीमा समाप्त हो गई है, तो इसे प्राथमिकता में टक्कर मिलती है…। चेतावनियों के साथ।
पढ़ने की समाप्ति कतार केवल तभी चेक की जाती है जब समय सीमा अनुसूचक रीड कतार का पुनर्मूल्यांकन करता है। पढ़ने के लिए इसका मतलब है कि स्ट्रीमिंग आईओ के मामले के अलावा हर बार एक क्रमबद्ध रीड भेजा जाता है। जबकि शेड्यूलर रीड क्यू से io स्ट्रीमिंग कर रहा है, रीड एक्सपायर का मूल्यांकन नहीं किया गया है। रीड क्यू का पुनर्मूल्यांकन करते समय, तर्क है
एक्सपायर्ड रीड्स की जांच करें (FIFO [टाइम ऑर्डर्ड] क्यू के प्रमुख को देखें) यह देखने के लिए जांचें कि क्या कैश्ड रीड पॉइंटर वैध है (इसलिए स्ट्रीमिंग नहीं होने पर भी, कैश्ड पॉइंटर को अभी भी प्राथमिकता दी जाती है, इसलिए सॉर्ट की गई कतार को एक स्वीप में टिप टू टेल ट्रैवर्स किया जाता है) सॉर्ट की गई कतार से पहला रीड चुनें (दूसरे स्वीप के लिए फिर से टिप पर शुरू करें) यदि एक्सपायर्ड रीड्स हैं, तो पहले वाले को फीफो से हटा लिया जाता है। ध्यान दें कि यह एक्सपायर्ड रीड तब रीड सॉर्ट ऑर्डरिंग के लिए नया नेक्सस है। इस समाप्त होने के बाद कैश्ड नेक्स्ट पॉइंटर को सॉर्ट कतार से अगले io को इंगित करने के लिए सेट किया जाएगा…। ध्यान देने वाली बात यह है कि एक बार जब वे अपनी समाप्ति तिथि पार कर लेते हैं, तो एल्गोरिथ्म केवल सभी समाप्त हो चुके io को निष्पादित नहीं करता है। यह समाप्त हो चुकी रीड क्यू को फिर से जाँचने से पहले 'राइट_स्टारवेड' सॉर्ट किए गए रीड्स को एक साथ बैच करके कुछ उचित प्रदर्शन को बनाए रखने की अनुमति देता है।
इसलिए, रीड एक्सपायर्ड आईओ के बीच किए जा सकने वाले आईओ की अधिकतम संख्या 2 * 'फीफो_बैच' * 'राइट्स_स्टारवेड' है। 'फीफो_बैच' स्ट्रीमिंग का एक सेट पहले समाप्त हो चुके रीड आईओ के बाद पढ़ता है और यदि यह स्ट्रीम लिखने की भूख की स्थिति का कारण बनती है, तो संभवतः एक और 'फीफो_बैच' स्ट्रीमिंग लिखती है। यह बदतर स्थिति है, जिसके बाद समाप्त हो चुकी कतार का पुनर्मूल्यांकन किया जाएगा। सबसे अच्छी बात यह है कि समाप्त हो चुकी रीड क्यू को छोड़े जाने से पहले एक पंक्ति में 'राइट_स्टार्व्ड' बार मूल्यांकन किया जाएगा क्योंकि राइट क्यू का उपयोग किया जाएगा।
राइट_एक्सपायर (पूर्णांक)
Read_expire के समान लेकिन लिखने के संचालन के लिए (रीड से अलग बैचों में समूहीकृत)।
लिखता_भूखा (पूर्णांक)
जैसा कि पहले कहा गया है, समय सीमा लिखने के लिए पढ़ना पसंद करती है। नतीजतन, यह उन स्थितियों को जन्म दे सकता है जहां संचालन निष्पादित किया जाता है लगभग पूरी तरह से पढ़ा जाता है। यह अधिक महत्वपूर्ण ट्यूनेबल हो जाता है क्योंकि राइट_एक्सपायर लंबा हो जाता है या समग्र बैंडविड्थ संतृप्ति तक पहुंच जाता है। इसे कम करने से रीड ऑपरेशंस की कीमत पर राइट्स (अपेक्षाकृत बोलने) के लिए अधिक बैंडविड्थ मिलती है। यदि एप्लिकेशन वर्कलोड, हालांकि, पढ़ने-भारी है (उदाहरण के लिए अधिकांश HTTP या निर्देशिका सर्वर) केवल कभी-कभी लिखने के साथ, औसत आईओपी की कम विलंबता इसे बढ़ाकर हासिल की जा सकती है (ताकि लिखने के बैच को कतारबद्ध करने से पहले और अधिक पढ़ना चाहिए। डिस्क के लिए)।
front_merges (बूल पूर्णांक)
एक फ्रंट मर्ज एक ऑपरेशन है जहां I/O अनुसूचक, छोटे अनुरोधों को कम (बड़े) संचालन में संघनित (या विलय) करने की मांग कर रहा है, एक नया ऑपरेशन करेगा, फिर सक्रिय बैच की जांच करेगा और संचालन का पता लगाने का प्रयास करेगा जहां शुरुआती क्षेत्र है एक ही या किसी अन्य ऑपरेशन के शुरुआती सेक्टर के तुरंत बाद। एक बैक मर्ज विपरीत है, जहां सक्रिय बैच में समाप्त होने वाले क्षेत्रों को उन क्षेत्रों के लिए खोजा जाता है जो या तो समान हैं या वर्तमान संचालन के शुरुआती क्षेत्रों के तुरंत बाद हैं। मर्ज करने से संचालन वर्तमान बैच से सक्रिय बैच में बदल जाता है, थ्रूपुट बढ़ाने के लिए निष्पक्षता कम हो जाती है।
जिस तरह से फाइलें आमतौर पर रखी जाती हैं, उसके कारण बैक मर्ज फ्रंट मर्ज की तुलना में बहुत अधिक सामान्य हैं। कुछ कार्यभार के लिए, आप यह भी जान सकते हैं कि किसी भी समय मर्ज अनुरोधों को आगे बढ़ाने का प्रयास करना समय की बर्बादी है। Front_merges को 0 पर सेट करने से यह कार्यक्षमता अक्षम हो जाती है। कैश्ड last_merge संकेत के कारण फ्रंट मर्ज अभी भी हो सकता है, लेकिन चूंकि यह मूल रूप से शून्य लागत पर आता है, यह अभी भी किया जाता है। जब I/O शेड्यूलर मर्जिंग फ़ंक्शन को कॉल किया जाता है, तो यह बूलियन केवल फ्रंट सेक्टर लुकअप को अक्षम कर देता है। डिस्क मर्ज योग प्रति-ब्लॉक डिवाइस / proc / डिस्कस्टैट्स में रिकॉर्ड किए जाते हैं।[1]
अन्य I/O अनुसूचक
- सीएफक्यू अनुसूचक
- अग्रिम समयबद्धन
- नोप अनुसूचक
संदर्भ
- ↑ 1.0 1.1 Jens Axboe (11 November 2002). "Deadline I/O scheduler tunables". Linux kernel documentation. Retrieved 20 November 2011.
- ↑ Jens Axboe (4 January 2002). "[PATCH][RFT] simple deadline I/O scheduler". Linux Kernel Mailing List Archive. Retrieved 6 July 2014.
- ↑ IBM (12 September 2013). "कर्नेल वर्चुअल मशीन (केवीएम) केवीएम के लिए सर्वोत्तम अभ्यास" (PDF). IBM. Archived from the original (PDF) on May 13, 2016. Retrieved 6 July 2014.
