建站
咨詢
售后
建站咨詢
新聞中心
網(wǎng)絡(luò)質(zhì)量及網(wǎng)絡(luò)性能一直是企業(yè)與個人所關(guān)心的重點，為此，許多網(wǎng)絡(luò)管理員和系統(tǒng)管理員通過不斷地研究和嘗試，試圖實現(xiàn)更好的網(wǎng)絡(luò)質(zhì)量服務(wù)（QoS）。在眾多的QoS技術(shù)中，Linux QoS 被認(rèn)為是一種簡便易行的解決方案。本文將深入探討Linux QoS的實現(xiàn)機制，幫助讀者理解Linux QoS的優(yōu)勢和限制，幫助讀者更好地應(yīng)用Linux QoS技術(shù)。
一、Linux QoS的概述
QoS（Quality of Service）質(zhì)量服務(wù)，是一種網(wǎng)絡(luò)技術(shù)，通過對網(wǎng)絡(luò)流量進(jìn)行控制和調(diào)整，來提高網(wǎng)絡(luò)的性能。Linux QoS是一種基于Linux內(nèi)核實現(xiàn)的QoS技術(shù)，通過對Linux內(nèi)核中的網(wǎng)絡(luò)流量進(jìn)行分類和控制，來實現(xiàn)各種QoS服務(wù)。
Linux QoS技術(shù)主要分類為三種：
（1）差異化服務(wù)（DiffServ），它是一種面向服務(wù)質(zhì)量的網(wǎng)絡(luò)架構(gòu)，可提供QoS級別服務(wù)，以便在網(wǎng)絡(luò)中向待分類流提供優(yōu)先級。當(dāng)網(wǎng)絡(luò)擁塞時，這些流的優(yōu)先級將確定其在網(wǎng)絡(luò)資源分配中的優(yōu)先級。該技術(shù)通常用于有限帶寬情況下的網(wǎng)絡(luò)。
（2）集成服務(wù)（IntServ），它利用公共網(wǎng)絡(luò)的服務(wù)質(zhì)量特征來提供服務(wù)質(zhì)量。此技術(shù)用于高速網(wǎng)絡(luò)和網(wǎng)絡(luò)中存在連續(xù)保證帶寬的應(yīng)用。在幾乎沒有擁塞的情況下，該技術(shù)會分配足夠的帶寬給每一個QoS流。
（3） 策略性選擇服務(wù)（PSS），它是一個以策略為基礎(chǔ)的聯(lián)盟，在一個聯(lián)盟中的用戶可以憑借自己的策略來訪問自己所需要的服務(wù)。這種技術(shù)在企業(yè)內(nèi)部網(wǎng)絡(luò)中經(jīng)常使用。
二、Linux QoS的實現(xiàn)方式
Linux QoS的實現(xiàn)方式主要包括三個方面：
（1）流量分類
Linux QoS的流量分類是通過將網(wǎng)絡(luò)中的流量進(jìn)行分類，并將其放入不同的隊列中，這些隊列可按照優(yōu)先級從高到低的順序進(jìn)行排列。Linux下的流量分類機制主要有基于 iptables 的流量分類和基于 tc 命令的流量分類。
（2）隊列調(diào)度
隊列調(diào)度是Linux QoS中用來調(diào)整流量的重要機制之一，其主要目的是對網(wǎng)絡(luò)流量進(jìn)行排隊、調(diào)度和按照一定的策略分配。隊列調(diào)度可實現(xiàn)不同流量的優(yōu)先級。
（3）流量控制
流量控制是Linux QoS的最后一個環(huán)節(jié)，主要用于根據(jù)不同應(yīng)用程序的需求，對流量進(jìn)行限制、控制。通過流量控制機制，可確保網(wǎng)絡(luò)的正常運行。
三、Linux QoS的應(yīng)用
（1）業(yè)務(wù)分級與限速
通過對網(wǎng)絡(luò)中的數(shù)據(jù)流進(jìn)行分類和限速，可以使得不同的業(yè)務(wù)擁有不同的優(yōu)先級，從而降低只負(fù)荷造成的瓶頸，實現(xiàn)網(wǎng)絡(luò)的負(fù)載均衡。
（2）視頻流優(yōu)先級
在觀看視頻時，如果網(wǎng)絡(luò)帶寬不足，會導(dǎo)致視頻的像素下降、畫面卡頓，用戶體驗大打折扣。使用Linux QoS技術(shù)，對視頻流的優(yōu)先級進(jìn)行提高，能夠使得視頻流在帶寬不足的情況下仍然能夠得到保證。
（3）游戲流優(yōu)先級
當(dāng)網(wǎng)絡(luò)有擁塞情況發(fā)生時，游戲可能會因為網(wǎng)絡(luò)卡頓或丟包而影響游戲體驗。通常來說，需要通過提高游戲的流量優(yōu)先級，讓重要數(shù)據(jù)包優(yōu)先傳輸，來保證網(wǎng)絡(luò)的高質(zhì)量和行暢。
四、Linux QoS的局限
盡管Linux QoS 在網(wǎng)絡(luò)帶寬管理和流量控制領(lǐng)域有很多優(yōu)秀的優(yōu)點，但也存在一些局限性。主要體現(xiàn)在以下幾個方面：
（1）Linux QoS技術(shù)對于新晉管理員使用門檻較高，需要對Linux的網(wǎng)絡(luò)原理和Linux實現(xiàn)QoS的機制有著更深入的了解。
（2）流量分類對硬件層面有著更高的需求，需要更高速的網(wǎng)路交換機支持，來確保較高級別的服務(wù)質(zhì)量。
結(jié)論：
Linux QoS 的實現(xiàn)機制及其應(yīng)用場景是一個極為廣泛的話題，隨著網(wǎng)絡(luò)技術(shù)的變化和網(wǎng)絡(luò)性能的需求增加，Linux QoS 技術(shù)必然會有新的發(fā)展。潛在的研究和應(yīng)用價值是無限的，我們需要在不斷摸索和實踐的過程中，不斷發(fā)現(xiàn)和探討。
相關(guān)問題拓展閱讀：
- 面試 linux 文件系統(tǒng)怎樣io到底層
- Linux下IPV4和IPV6的互操作性研究
面試 linux 文件系統(tǒng)怎樣io到底層
前言：本文主要講解LinuxIO調(diào)度層的三種模式：cfp、deadline和noop，并給出各自的優(yōu)化和適用場景建議。IO調(diào)度發(fā)生在Linux內(nèi)核的IO調(diào)度層。這個層次是針對Linux的整體IO層次體系來說的。從read()或者write()系統(tǒng)調(diào)用的角度來說，Linux整體IO體系可以分為七層，它們分別是：VFS層：虛擬文件系統(tǒng)層。由于內(nèi)核要跟多種文件系統(tǒng)打交道，而每一種文件系統(tǒng)所實現(xiàn)的數(shù)據(jù)結(jié)構(gòu)和相關(guān)方法都可能不盡相同，所以，內(nèi)核抽象了這一層，專門用來適配各種文件系統(tǒng)，并對外提供統(tǒng)一操作接口。文件系統(tǒng)層：不同的文件系統(tǒng)實現(xiàn)自己的操作過程，提供自己特有的特征，具體不多說了，大家愿意的話自己去看代碼即可。頁緩存層：負(fù)責(zé)真對page的緩存。通用塊層：由于絕大多數(shù)情況的io操作是跟塊設(shè)備打交道，所以Linux在此提供了一個類似vfs層的塊設(shè)備操作抽象層。下層對接各種不同屬性的塊設(shè)備，對上提供統(tǒng)一的BlockIO請求標(biāo)準(zhǔn)。IO調(diào)度層：因為絕大多數(shù)的塊設(shè)備都是類似磁盤這樣的設(shè)備，所以有必要根據(jù)這類設(shè)備的特點以及應(yīng)用的不同特點來設(shè)置一些不同的調(diào)度算法和隊列。以便在不同的應(yīng)用環(huán)境下有針對性的提高磁盤的讀寫效率，這里就是大名鼎鼎的Linux電梯所起作用的地方。針對機械硬盤的各種調(diào)度方法就是在這實現(xiàn)的。塊設(shè)備驅(qū)動層：驅(qū)動層對外提供相對比較高級的設(shè)備操作接口，往往是C語言的，而下層對接設(shè)備本身的操作方法和規(guī)范。塊設(shè)備層：這層就是具體的物理設(shè)備了，定義了各種真對設(shè)備操作方法和規(guī)范。有一個已經(jīng)整理好的，非常經(jīng)典，一圖勝千言：我們今天要研究的內(nèi)容主要在IO調(diào)度這一層。它要解決的核心問題是，如何提高塊設(shè)備IO的整體性能？這一層也主要是針對機械硬盤結(jié)構(gòu)而設(shè)計的。眾所周知，機械硬盤的存儲介質(zhì)是磁盤，磁頭在盤片上移動進(jìn)行磁道尋址，行為類似播放一張唱片。這種結(jié)構(gòu)的特點是，順序訪問時吞吐量較高，但是如果一旦對盤片有隨機訪問，那么大量的時間都會浪費在磁頭的移動上，這時候就會導(dǎo)致每次IO的響應(yīng)時間變長，極大的降低IO的響應(yīng)速度。磁頭在盤片上尋道的操作，類似電梯調(diào)度，實際上在最開始的時期，Linux把這個算法命名為Linux電梯算法，即：如果在尋道的過程中，能把順序路過的相關(guān)磁道的數(shù)據(jù)請求都“順便”處理掉，那么就可以在比較小影響響應(yīng)速度的前提下，提高整體IO的吞吐量。這就是我們?yōu)槭裁匆O(shè)計IO調(diào)度算法的原因。目前在內(nèi)核中默認(rèn)開啟了三種算法/模式：noop，cfq和deadline。嚴(yán)格算應(yīng)該是兩種：因為之一種叫做noop，就是空操作調(diào)度算法，也就是沒有任何調(diào)度操作，并不對io請求進(jìn)行排序，僅僅做適當(dāng)?shù)膇o合并的一個fifo隊列。目前內(nèi)核中默認(rèn)的調(diào)度算法應(yīng)該是cfq，叫做完全公平隊列調(diào)度。這個調(diào)度算法人如其名，它試圖給所有進(jìn)程提供一個完全公平的IO操作環(huán)境。注：請大家一定記住這個詞語，cfq，完全公平隊列調(diào)度，不然下文就沒法看了。cfq為每個進(jìn)程創(chuàng)建一個同步IO調(diào)度隊列，并默認(rèn)以時間片和請求數(shù)限定的方式分配IO資源，以此保證每個進(jìn)程的IO資源占用是公平的，cfq還實現(xiàn)了針對進(jìn)程級別的優(yōu)先級調(diào)度，這個我們后面會詳細(xì)解釋。查看和修改IO調(diào)度算法的方法是：cfq是通用服務(wù)器比較好的IO調(diào)度算法選擇，對桌面用戶也是比較好的選擇。但是對于很多IO壓力較大的場景就并不是很適應(yīng)，尤其是IO壓力集中在某些進(jìn)程上的場景。因為這種場景我們需要的滿足某個或者某幾個進(jìn)程的IO響應(yīng)速度，而不是讓所有的進(jìn)程公平的使用IO，比如數(shù)據(jù)庫應(yīng)用。deadline調(diào)度（最終期限調(diào)度）就是更適合上述場景的解決方案。deadline實現(xiàn)了四個隊列：其中兩個分別處理正常read和write，按扇區(qū)號排序，進(jìn)行正常io的合并處理以提高吞吐量。因為IO請求可能會集中在某些磁盤位置，這樣會導(dǎo)致新來的請求一直被合并，可能會有其他磁盤位置的io請求被餓死。另外兩個處理超時read和write的隊列，按請求創(chuàng)建時間排序，如果有超時的請求出現(xiàn)，就放進(jìn)這兩個隊列，調(diào)度算法保證超時（達(dá)到最終期限時間）的隊列中的請求會優(yōu)先被處理，防止請求被餓死。不久前，內(nèi)核還是默認(rèn)標(biāo)配四種算法，還有一種叫做as的算法（Anticipatoryscheduler），預(yù)測調(diào)度算法。一個高大上的名字，搞得我一度認(rèn)為Linux內(nèi)核都會算命了。結(jié)果發(fā)現(xiàn)，無非是在基于deadline算法做io調(diào)度的之前等一小會時間，如果這段時間內(nèi)有可以合并的io請求到來，就可以合并處理，提高deadline調(diào)度的在順序讀寫情況下的數(shù)據(jù)吞吐量。其實這根本不是啥預(yù)測，我覺得不如叫撞大運調(diào)度算法，當(dāng)然這種策略在某些特定場景差效果不錯。但是在大多數(shù)場景下，這個調(diào)度不僅沒有提高吞吐量，還降低了響應(yīng)速度，所以內(nèi)核干脆把它從默認(rèn)配置里刪除了。畢竟Linux的宗旨是實用，而我們也就不再這個調(diào)度算法上多費口舌了。1、cfq：完全公平隊列調(diào)度cfq是內(nèi)核默認(rèn)選擇的IO調(diào)度隊列，它在桌面應(yīng)用場景以及大多數(shù)常見應(yīng)用場景下都是很好的選擇。如何實現(xiàn)一個所謂的完全公平隊列（CompletelyFairQueueing）？首先我們要理解所謂的公平是對誰的公平？從操作系統(tǒng)的角度來說，產(chǎn)生操作行為的主體都是進(jìn)程，所以這里的公平是針對每個進(jìn)程而言的，我們要試圖讓進(jìn)程可以公平的占用IO資源。那么如何讓進(jìn)程公平的占用IO資源？我們需要先理解什么是IO資源。當(dāng)我們衡量一個IO資源的時候，一般喜歡用的是兩個單位，一個是數(shù)據(jù)讀寫的帶寬，另一個是數(shù)據(jù)讀寫的IOPS。帶寬就是以時間為單位的讀寫數(shù)據(jù)量，比如，100Mbyte/s。而IOPS是以時間為單位的讀寫次數(shù)。在不同的讀寫情境下，這兩個單位的表現(xiàn)可能不一樣，但是可以確定的是，兩個單位的任何一個達(dá)到了性能上限，都會成為IO的瓶頸。從機械硬盤的結(jié)構(gòu)考慮，如果讀寫是順序讀寫，那么IO的表現(xiàn)是可以通過比較少的IOPS達(dá)到較大的帶寬，因為可以合并很多IO，也可以通過預(yù)讀等方式加速數(shù)據(jù)讀取效率。當(dāng)IO的表現(xiàn)是偏向于隨機讀寫的時候，那么IOPS就會變得更大，IO的請求的合并可能性下降，當(dāng)每次io請求數(shù)據(jù)越少的時候，帶寬表現(xiàn)就會越低。從這里我們可以理解，針對進(jìn)程的IO資源的主要表現(xiàn)形式有兩個：進(jìn)程在單位時間內(nèi)提交的IO請求個數(shù)和進(jìn)程占用IO的帶寬。其實無論哪個，都是跟進(jìn)程分配的IO處理時間長度緊密相關(guān)的。有時業(yè)務(wù)可以在較少IOPS的情況下占用較大帶寬，另外一些則可能在較大IOPS的情況下占用較少帶寬，所以對進(jìn)程占用IO的時間進(jìn)行調(diào)度才是相對最公平的。即，我不管你是IOPS高還是帶寬占用高，到了時間咱就換下一個進(jìn)程處理，你愛咋樣咋樣。所以，cfq就是試圖給所有進(jìn)程分配等同的塊設(shè)備使用的時間片，進(jìn)程在時間片內(nèi)，可以將產(chǎn)生的IO請求提交給塊設(shè)備進(jìn)行處理，時間片結(jié)束，進(jìn)程的請求將排進(jìn)它自己的隊列，等待下次調(diào)度的時候進(jìn)行處理。這就是cfq的基本原理。當(dāng)然，現(xiàn)實生活中不可能有真正的“公平”，常見的應(yīng)用場景下，我們很肯能需要人為的對進(jìn)程的IO占用進(jìn)行人為指定優(yōu)先級，這就像對進(jìn)程的CPU占用設(shè)置優(yōu)先級的概念一樣。所以，除了針對時間片進(jìn)行公平隊列調(diào)度外，cfq還提供了優(yōu)先級支持。每個進(jìn)程都可以設(shè)置一個IO優(yōu)先級，cfq會根據(jù)這個優(yōu)先級的設(shè)置情況作為調(diào)度時的重要參考因素。優(yōu)先級首先分成三大類：RT、BE、IDLE，它們分別是實時（RealTime）、更佳效果（BestTry）和閑置（Idle）三個類別，對每個類別的IO，cfq都使用不同的策略進(jìn)行處理。另外，RT和BE類別中，分別又再劃分了8個子優(yōu)先級實現(xiàn)更細(xì)節(jié)的QOS需求，而IDLE只有一個子優(yōu)先級。另外，我們都知道內(nèi)核默認(rèn)對存儲的讀寫都是經(jīng)過緩存（buffer/cache）的，在這種情況下，cfq是無法區(qū)分當(dāng)前處理的請求是來自哪一個進(jìn)程的。只有在進(jìn)程使用同步方式（syncread或者syncwirte）或者直接IO（DirectIO）方式進(jìn)行讀寫的時候，cfq才能區(qū)分出IO請求來自哪個進(jìn)程。所以，除了針對每個進(jìn)程實現(xiàn)的IO隊列以外，還實現(xiàn)了一個公共的隊列用來處理異步請求。當(dāng)前內(nèi)核已經(jīng)實現(xiàn)了針對IO資源的cgroup資源隔離，所以在以上體系的基礎(chǔ)上，cfq也實現(xiàn)了針對cgroup的調(diào)度支持?？偟膩碚f，cfq用了一系列的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)了以上所有復(fù)雜功能的支持，大家可以通過源代碼看到其相關(guān)實現(xiàn)，文件在源代碼目錄下的block/cfq-iosched.c。1.1cfq設(shè)計原理在此，我們對整體數(shù)據(jù)結(jié)構(gòu)做一個簡要描述：首先，cfq通過一個叫做cfq_data的數(shù)據(jù)結(jié)構(gòu)維護(hù)了整個調(diào)度器流程。在一個支持了cgroup功能的cfq中，全部進(jìn)程被分成了若干個contralgroup進(jìn)行管理。每個cgroup在cfq中都有一個cfq_group的結(jié)構(gòu)進(jìn)行描述，所有的cgroup都被作為一個調(diào)度對象放進(jìn)一個紅黑樹中，并以vdisktime為key進(jìn)行排序。vdisktime這個時間紀(jì)錄的是當(dāng)前cgroup所占用的io時間，每次對cgroup進(jìn)行調(diào)度時，總是通過紅黑樹選擇當(dāng)前vdisktime時間最少的cgroup進(jìn)行處理，以保證所有cgroups之間的IO資源占用“公平”。當(dāng)然我們知道，cgroup是可以對blkio進(jìn)行資源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime時間增長較慢，分配比例小的vdisktime時間增長較快，快慢與分配比例成正比。這樣就做到了不同的cgroup分配的IO比例不一樣，并且在cfq的角度看來依然是“公平“的。選擇好了需要處理的cgroup（cfq_group）之后，調(diào)度器需要決策選擇下一步的service_tree。service_tree這個數(shù)據(jù)結(jié)構(gòu)對應(yīng)的都是一系列的紅黑樹，主要目的是用來實現(xiàn)請求優(yōu)先級分類的，就是RT、BE、IDLE的分類。每一個cfq_group都維護(hù)了7個service_trees，其定義如下：其中service_tree_idle就是用來給IDLE類型的請求進(jìn)行排隊用的紅黑樹。而上面二維數(shù)組，首先之一個維度針對RT和BE分別各實現(xiàn)了一個數(shù)組，每一個數(shù)組中都維護(hù)了三個紅黑樹，分別對應(yīng)三種不同子類型的請求，分別是：SYNC、SYNC_NOIDLE以及ASYNC。我們可以認(rèn)為SYNC相當(dāng)于SYNC_IDLE并與SYNC_NOIDLE對應(yīng)。idling是cfq在設(shè)計上為了盡量合并連續(xù)的IO請求以達(dá)到提高吞吐量的目的而加入的機制，我們可以理解為是一種“空轉(zhuǎn)”等待機制?？辙D(zhuǎn)是指，當(dāng)一個隊列處理一個請求結(jié)束后，會在發(fā)生調(diào)度之前空等一小會時間，如果下一個請求到來，則可以減少磁頭尋址，繼續(xù)處理順序的IO請求。為了實現(xiàn)這個功能，cfq在service_tree這層數(shù)據(jù)結(jié)構(gòu)這實現(xiàn)了SYNC隊列，如果請求是同步順序請求，就入隊這個servicetree，如果請求是同步隨機請求，則入隊SYNC_NOIDLE隊列，以判斷下一個請求是否是順序請求。所有的異步寫操作請求將入隊ASYNC的servicetree，并且針對這個隊列沒有空轉(zhuǎn)等待機制。此外，cfq還對SSD這樣的硬盤有特殊調(diào)整，當(dāng)cfq發(fā)現(xiàn)存儲設(shè)備是一個ssd硬盤這樣的隊列深度更大的設(shè)備時，所有針對單獨隊列的空轉(zhuǎn)都將不生效，所有的IO請求都將入隊SYNC_NOIDLE這個servicetree。每一個servicetree都對應(yīng)了若干個cfq_queue隊列，每個cfq_queue隊列對應(yīng)一個進(jìn)程，這個我們后續(xù)再詳細(xì)說明。cfq_group還維護(hù)了一個在cgroup內(nèi)部所有進(jìn)程公用的異步IO請求隊列，其結(jié)構(gòu)如下：異步請求也分成了RT、BE、IDLE這三類進(jìn)行處理，每一類對應(yīng)一個cfq_queue進(jìn)行排隊。BE和RT也實現(xiàn)了優(yōu)先級的支持，每一個類型有IOPRIO_BE_NR這么多個優(yōu)先級，這個值定義為8，數(shù)組下標(biāo)為0-7。我們目前分析的內(nèi)核代碼版本為Linux4.4，可以看出，從cfq的角度來說，已經(jīng)可以實現(xiàn)異步IO的cgroup支持了，我們需要定義一下這里所謂異步IO的含義，它僅僅表示從內(nèi)存的buffer/cache中的數(shù)據(jù)同步到硬盤的IO請求，而不是aio(man7aio)或者linux的native異步io以及l(fā)ibaio機制，實際上這些所謂的“異步”IO機制，在內(nèi)核中都是同步實現(xiàn)的（本質(zhì)上馮諾伊曼計算機沒有真正的“異步”機制）。我們在上面已經(jīng)說明過，由于進(jìn)程正常情況下都是將數(shù)據(jù)先寫入buffer/cache，所以這種異步IO都是統(tǒng)一由cfq_group中的async請求隊列處理的。那么為什么在上面的service_tree中還要實現(xiàn)和一個ASYNC的類型呢？這當(dāng)然是為了支持區(qū)分進(jìn)程的異步IO并使之可以“完全公平”做準(zhǔn)備嘍。實際上在最新的cgroupv2的blkio體系中，內(nèi)核已經(jīng)支持了針對bufferIO的cgroup限速支持，而以上這些可能容易混淆的一堆類型，都是在新的體系下需要用到的類型標(biāo)記。新體系的復(fù)雜度更高了，功能也更加強大，但是大家先不要著急，正式的cgroupv2體系，在Linux4.5發(fā)布的時候會正式跟大家見面。我們繼續(xù)選擇service_tree的過程，三種優(yōu)先級類型的service_tree的選擇就是根據(jù)類型的優(yōu)先級來做選擇的，RT優(yōu)先級更高，BE其次，IDLE更低。就是說，RT里有，就會一直處理RT，RT沒了再處理BE。每個service_tree對應(yīng)一個元素為cfq_queue排隊的紅黑樹，而每個cfq_queue就是內(nèi)核為進(jìn)程（線程）創(chuàng)建的請求隊列。每一個cfq_queue都會維護(hù)一個rb_key的變量，這個變量實際上就是這個隊列的IO服務(wù)時間（servicetime）。這里還是通過紅黑樹找到servicetime時間最短的那個cfq_queue進(jìn)行服務(wù)，以保證“完全公平”。選擇好了cfq_queue之后，就要開始處理這個隊列里的IO請求了。這里的調(diào)度方式基本跟deadline類似。cfq_queue會對進(jìn)入隊列的每一個請求進(jìn)行兩次入隊，一個放進(jìn)fifo中，另一個放進(jìn)按訪問扇區(qū)順序作為key的紅黑樹中。默認(rèn)從紅黑樹中取請求進(jìn)行處理，當(dāng)請求的延時時間達(dá)到deadline時，就從紅黑樹中取等待時間最長的進(jìn)行處理，以保證請求不被餓死。這就是整個cfq的調(diào)度流程，當(dāng)然其中還有很多細(xì)枝末節(jié)沒有交代，比如合并處理以及順序處理等等。1.2cfq的參數(shù)調(diào)整理解整個調(diào)度流程有助于我們決策如何調(diào)整cfq的相關(guān)參數(shù)。所有cfq的可調(diào)參數(shù)都可以在/sys/class/block/sda/queue/iosched/目錄下找到，當(dāng)然，在你的系統(tǒng)上，請將sda替換為相應(yīng)的磁盤名稱。我們來看一下都有什么：這些參數(shù)部分是跟機械硬盤磁頭尋道方式有關(guān)的，如果其說明你看不懂，請先補充相關(guān)知識：back_seek_max:磁頭可以向后尋址的更大范圍，默認(rèn)值為16M。back_seek_penalty:向后尋址的懲罰系數(shù)。這個值是跟向前尋址進(jìn)行比較的。以上兩個是為了防止磁頭尋道發(fā)生抖動而導(dǎo)致尋址過慢而設(shè)置的?；舅悸肥沁@樣，一個io請求到來的時候，cfq會根據(jù)其尋址位置預(yù)估一下其磁頭尋道成本。設(shè)置一個更大值back_seek_max，對于請求所訪問的扇區(qū)號在磁頭后方的請求，只要尋址范圍沒有超過這個值，cfq會像向前尋址的請求一樣處理它。再設(shè)置一個評估成本的系數(shù)back_seek_penalty，相對于磁頭向前尋址，向后尋址的距離為1/2(1/back_seek_penalty)時，cfq認(rèn)為這兩個請求尋址的代價是相同。這兩個參數(shù)實際上是cfq判斷請求合并處理的條件限制，凡事復(fù)合這個條件的請求，都會盡量在本次請求處理的時候一起合并處理。fifo_expire_async:設(shè)置異步請求的超時時間。同步請求和異步請求是區(qū)分不同隊列處理的，cfq在調(diào)度的時候一般情況都會優(yōu)先處理同步請求，之后再處理異步請求，除非異步請求符合上述合并處理的條件限制范圍內(nèi)。當(dāng)本進(jìn)程的隊列被調(diào)度時，cfq會優(yōu)先檢查是否有異步請求超時，就是超過fifo_expire_async參數(shù)的限制。如果有，則優(yōu)先發(fā)送一個超時的請求，其余請求仍然按照優(yōu)先級以及扇區(qū)編號大小來處理。fifo_expire_sync:這個參數(shù)跟上面的類似，區(qū)別是用來設(shè)置同步請求的超時時間。slice_idle:參數(shù)設(shè)置了一個等待時間。這讓cfq在切換cfq_queue或servicetree的時候等待一段時間，目的是提高機械硬盤的吞吐量。一般情況下，來自同一個cfq_queue或者servicetree的IO請求的尋址局部性更好，所以這樣可以減少磁盤的尋址次數(shù)。這個值在機械硬盤上默認(rèn)為非零。當(dāng)然在固態(tài)硬盤或者硬RAID設(shè)備上設(shè)置這個值為非零會降低存儲的效率，因為固態(tài)硬盤沒有磁頭尋址這個概念，所以在這樣的設(shè)備上應(yīng)該設(shè)置為0，關(guān)閉此功能。group_idle:這個參數(shù)也跟上一個參數(shù)類似，區(qū)別是當(dāng)cfq要切換cfq_group的時候會等待一段時間。在cgroup的場景下，如果我們沿用slice_idle的方式，那么空轉(zhuǎn)等待可能會在cgroup組內(nèi)每個進(jìn)程的cfq_queue切換時發(fā)生。這樣會如果這個進(jìn)程一直有請求要處理的話，那么直到這個cgroup的配額被耗盡，同組中的其它進(jìn)程也可能無法被調(diào)度到。這樣會導(dǎo)致同組中的其它進(jìn)程餓死而產(chǎn)生IO性能瓶頸。在這種情況下，我們可以將slice_idle＝0而group_idle＝8。這樣空轉(zhuǎn)等待就是以cgroup為單位進(jìn)行的，而不是以cfq_queue的進(jìn)程為單位進(jìn)行，以防止上述問題產(chǎn)生。low_latency:這個是用來開啟或關(guān)閉cfq的低延時（lowlatency）模式的開關(guān)。當(dāng)這個開關(guān)打開時，cfq將會根據(jù)target_latency的參數(shù)設(shè)置來對每一個進(jìn)程的分片時間（slicetime）進(jìn)行重新計算。這將有利于對吞吐量的公平（默認(rèn)是對時間片分配的公平）。關(guān)閉這個參數(shù)（設(shè)置為0）將忽略target_latency的值。這將使系統(tǒng)中的進(jìn)程完全按照時間片方式進(jìn)行IO資源分配。這個開關(guān)默認(rèn)是打開的。我們已經(jīng)知道cfq設(shè)計上有“空轉(zhuǎn)”（idling）這個概念，目的是為了可以讓連續(xù)的讀寫操作盡可能多的合并處理，減少磁頭的尋址操作以便增大吞吐量。如果有進(jìn)程總是很快的進(jìn)行順序讀寫，那么它將因為cfq的空轉(zhuǎn)等待命中率很高而導(dǎo)致其它需要處理IO的進(jìn)程響應(yīng)速度下降，如果另一個需要調(diào)度的進(jìn)程不會發(fā)出大量順序IO行為的話，系統(tǒng)中不同進(jìn)程IO吞吐量的表現(xiàn)就會很不均衡。就比如，系統(tǒng)內(nèi)存的cache中有很多臟頁要寫回時，桌面又要打開一個瀏覽器進(jìn)行操作，這時臟頁寫回的后臺行為就很可能會大量命中空轉(zhuǎn)時間，而導(dǎo)致瀏覽器的小量IO一直等待，讓用戶感覺瀏覽器運行響應(yīng)速度變慢。這個low_latency主要是對這種情況進(jìn)行優(yōu)化的選項，當(dāng)其打開時，系統(tǒng)會根據(jù)target_latency的配置對因為命中空轉(zhuǎn)而大量占用IO吞吐量的進(jìn)程進(jìn)行限制，以達(dá)到不同進(jìn)程IO占用的吞吐量的相對均衡。這個開關(guān)比較合適在類似桌面應(yīng)用的場景下打開。target_latency:當(dāng)low_latency的值為開啟狀態(tài)時，cfq將根據(jù)這個值重新計算每個進(jìn)程分配的IO時間片長度。quantum:這個參數(shù)用來設(shè)置每次從cfq_queue中處理多少個IO請求。在一個隊列處理事件周期中，超過這個數(shù)字的IO請求將不會被處理。這個參數(shù)只對同步的請求有效。slice_sync:當(dāng)一個cfq_queue隊列被調(diào)度處理時，它可以被分配的處理總時間是通過這個值來作為一個計算參數(shù)指定的。公式為：time_slice=slice_sync+(slice_sync/5*(4-prio))。這個參數(shù)對同步請求有效。slice_async:這個值跟上一個類似，區(qū)別是對異步請求有效。slice_async_rq:這個參數(shù)用來限制在一個slice的時間范圍內(nèi)，一個隊列最多可以處理的異步請求個數(shù)。請求被處理的更大個數(shù)還跟相關(guān)進(jìn)程被設(shè)置的io優(yōu)先級有關(guān)。1.3cfq的IOPS模式我們已經(jīng)知道，默認(rèn)情況下cfq是以時間片方式支持的帶優(yōu)先級的調(diào)度來保證IO資源占用的公平。高優(yōu)先級的進(jìn)程將得到的時間片長度，而低優(yōu)先級的進(jìn)程時間片相對較小。當(dāng)我們的存儲是一個高速并且支持NCQ（原生指令隊列）的設(shè)備的時候，我們更好可以讓其可以從多個cfq隊列中處理多路的請求，以便提升NCQ的利用率。此時使用時間片的分配方式分配資源就顯得不合時宜了，因為基于時間片的分配，同一時刻最多能處理的請求隊列只有一個。這時，我們需要切換cfq的模式為IOPS模式。切換方式很簡單，就是將slice_idle=0即可。內(nèi)核會自動檢測你的存儲設(shè)備是否支持NCQ，如果支持的話cfq會自動切換為IOPS模式。另外，在默認(rèn)的基于優(yōu)先級的時間片方式下，我們可以使用ionice命令來調(diào)整進(jìn)程的IO優(yōu)先級。進(jìn)程默認(rèn)分配的IO優(yōu)先級是根據(jù)進(jìn)程的nice值計算而來的，計算方法可以在manionice中看到，這里不再廢話。2、deadline：最終期限調(diào)度deadline調(diào)度算法相對cfq要簡單很多。其設(shè)計目標(biāo)是：在保證請求按照設(shè)備扇區(qū)的順序進(jìn)行訪問的同時，兼顧其它請求不被餓死，要在一個最終期限前被調(diào)度到。我們知道磁頭對磁盤的尋道是可以進(jìn)行順序訪問和隨機訪問的，因為尋道延時時間的關(guān)系，順序訪問時IO的吞吐量更大，隨機訪問的吞吐量小。如果我們想為一個機械硬盤進(jìn)行吞吐量優(yōu)化的話，那么就可以讓調(diào)度器按照盡量復(fù)合順序訪問的IO請求進(jìn)行排序，之后請求以這樣的順序發(fā)送給硬盤，就可以使IO的吞吐量更大。但是這樣做也有另一個問題，就是如果此時出現(xiàn)了一個請求，它要訪問的磁道離目前磁頭所在磁道很遠(yuǎn)，應(yīng)用的請求又大量集中在目前磁道附近。導(dǎo)致大量請求一直會被合并和插隊處理，而那個要訪問比較遠(yuǎn)磁道的請求將因為一直不能被調(diào)度而餓死。deadline就是這樣一種調(diào)度器，能在保證IO更大吞吐量的情況下，盡量使遠(yuǎn)端請求在一個期限內(nèi)被調(diào)度而不被餓死的調(diào)度器。
Linux下IPV4和IPV6的互操作性研究
作為向下一代互聯(lián)網(wǎng)絡(luò)協(xié)議過渡的重要步驟 國際的IPv 試驗網(wǎng) bone在 年成立扒胡滑了 現(xiàn)在 bone已經(jīng)擴(kuò)展到全球 多個國家和地區(qū) 成為IPv 研究者 開發(fā)者和實踐者的主要平臺 CERNET國家網(wǎng)絡(luò)中心于 年 月加入 bone 同年 月成為其骨干網(wǎng)成員 電子科大作為教育網(wǎng)的西南主節(jié)點 在得到Nokia的IPv 路由器之后 積極參與IPv 技術(shù)研究 我們先查閱研究了大多數(shù)與IPv 有關(guān)的RFC文檔和相關(guān)技術(shù)資料 并且在此基礎(chǔ)上進(jìn)行了很多網(wǎng)絡(luò)實驗 該文先簡單闡述了IPV 的必要性和IPV 到IPV 升級轉(zhuǎn)換的機制 然后詳細(xì)闡明了在Linux操作系統(tǒng)下進(jìn)行的IPv 網(wǎng)絡(luò)實驗及其結(jié)論 并附有相關(guān)參考文獻(xiàn)書目 一 使用IPv 的必要性現(xiàn)在運行的因特網(wǎng)協(xié)議IPv 存在其固有的局限性 一是地址問題 IPv 的地址只有 位 這意味著總的地址數(shù)大約是 億 并且還有許多地址是不可用的 按照目前網(wǎng)絡(luò)的發(fā)春臘展趨勢 到 和 年之間IPv 的地址就會耗盡 必須用另一種地址方案來替代它 二是IPv 提供的服務(wù)局限性 IPv 盡它的更大努力來傳送信息包 但是它不會保證提供給上層的服務(wù)是可靠的 沒有QoS（服務(wù)質(zhì)量）的概念 這些問題都是IPv 的薄弱環(huán)節(jié) 致命弱點 另外因特網(wǎng)不斷提出對移動性 安全性以及多媒體業(yè)務(wù)的支持等問題 IPv 都無法解決 這樣就迫使我們必須引入下一帶因特網(wǎng)協(xié)議 IPv 二 IPv 和IPv 的互操作要將現(xiàn)在的IPV 網(wǎng)絡(luò)升級到IPV 網(wǎng)絡(luò) 不可能所有的機器在同時啟用IPV 協(xié)議棧 配置好IPV 地址 安裝好IPV 應(yīng)用程序 所以必須實現(xiàn)IPV 網(wǎng)絡(luò)與IPV 網(wǎng)絡(luò)之間的互操作及平滑升級機制 IPv 到IPv 的升級轉(zhuǎn)換機制的首要條件是允許IPv 和IPv 主機互操作 其次是在相互依賴性很小的情況下使IPv 的主機和路由器能在因特網(wǎng)中快速發(fā)展 第三是轉(zhuǎn)換對端用戶 系統(tǒng)管理員和網(wǎng)絡(luò)實施者來說易于理解和執(zhí)行 IPv 轉(zhuǎn)換機制是一套主機和路由器執(zhí)行的協(xié)議機制 有一套定址和配置的操作指導(dǎo)方案 盡可能減少轉(zhuǎn)換過程中造成的破壞 IPv 轉(zhuǎn)換機制的主要目標(biāo)如下 · 可增加的升級和擴(kuò)展性:單個IPv 的主機和路由器可在不需要其它的主機和路由器同時升級的情況下單獨升級成IPv 新的IPv 主機和路由器可以后再一臺臺的安裝成IPv ·最小的升級依賴性 將主機升級成IPv 的唯一先決條件是域名服務(wù)器必須先升級以處理IPv 地址記錄 ·方便的尋址 當(dāng)IPv 的主機和路由器升級到IPv 后 他們必須繼續(xù)用原來的地址 他們不需要指定新的地址 管理者不需制定新的地址分配方案 ·很低的啟動開銷 將IPv 系統(tǒng)升級成IPv 很少或幾乎不需要準(zhǔn)備工作 IPv 轉(zhuǎn)換機制確保IPv 主機能和任何因特網(wǎng)上的IPv 通信 直到IPv 被淘汰 并在那時允許在小范圍內(nèi)互相通信 這個特征保護(hù)了用戶已經(jīng)在IPv 上的巨大投入并使得IPv 不會將IPv 孤立 基于以上原因 IPv 主機和路由器上與Ipv 主機和路由器現(xiàn)在廣泛采用了如下兩種互操作的機制 隧道技術(shù)和雙IP協(xié)議棧技做衡術(shù)A．隧道技術(shù)隧道提供了一種利用IPv 路由基礎(chǔ)上傳輸IPv 包的方法 隧道應(yīng)用于下面幾種應(yīng)用中 路由器到路由器 主機到路由器 主機到主機和路由器到主機 路由器到路由器和主機到路由器隧道技術(shù)都是將IPv 包傳到路由器 隧道的終點是中間路由器 必須將IPv 包解出 并且轉(zhuǎn)發(fā)到它的目的地 隧道終點的地址必須由配置隧道節(jié)點的配置信息獲得 這種類型的隧道稱作人工配置隧道 當(dāng)利用隧道到達(dá)IPv 的主干網(wǎng)時 如果一個在IPv 網(wǎng)絡(luò)和IPv 網(wǎng)絡(luò)邊界的IPv /IPv 路由器的IPv 地址已知時 那么隧道的端點可以配置為這個路由器 這個隧道的配置可以被寫進(jìn)路由表中作為 缺省路由 這就是說所有IPv 目的地址符合此路由的都可以使用這條隧道 這種隧道就是默認(rèn)配置的隧道 主機到主機和路由器到主機隧道技術(shù)都是將IPv 包傳到主機的 可以用IPv 包的信息獲得終點地址 隧道入口創(chuàng)建一個IPv 封裝頭并傳送包 隧道出口解包 去掉IPv 頭 更新IPv 頭 處理IPv 包 隧道入口節(jié)點需要保存隧道信息如MTU等 如果用于目的節(jié)點的IPv 地址是與IPv 兼容的地址 隧道的IPv 地址可以自動從IPv 地址繼承下來 因此也就不需要人工配置 這種隧道也就稱為自動隧道 IPv 兼容的IPv 地址格式如下B．雙IP協(xié)議棧方式雙協(xié)議棧方式包括提供IPv 和IPv 協(xié)議棧的主機和路由器 雙協(xié)議棧工作方式的簡單描述如下 ·如果應(yīng)用程序使用的目的地址是IPv 地址 那么將使用IPv 協(xié)議棧 ·如果應(yīng)用程序使用的目的地址是兼容IPv 的IPv 地址 那么IPv 就封裝到IPv 中 ·如果目的地址是另一種類型的IPv 地址 那么就使用IPv 地址 可能封裝在默認(rèn)配置的隧道中 雙協(xié)議棧的缺省IP包發(fā)送算法為 a 如果IP包的目的地址是IPv 地址 如果目的站點在可達(dá)鏈路上 直接發(fā)送 如果目的站點不可達(dá) 要么送往在線路由器 要么不可達(dá) b 如果IP包的目的地址是IPv 兼容的IPv 地址 如果目的站點在可達(dá)鏈路上 直接發(fā)送IPv 包 如果目的站點處于off link （ ）如果有可達(dá)IPv 路由器 則封裝在IPv 包中發(fā)往IPv 路由器 （ ）如果有可達(dá)IPv 路由器 則不封裝 直接發(fā)送 （ ）如果沒有可達(dá)路由器 則不可達(dá) c 如果IP包的目的地址是純IPv 地址 如果目的站點在 可達(dá)鏈路上 直接發(fā)送IPv 包 如果目的站點處于off link （ ）如果有可達(dá)IPv 路由器 則直接發(fā)送到路由器 （ 如果目的地通過手動隧道可達(dá) 并且鏈路上有可達(dá)IPv 路由器 則封裝成IPv 包 目的IP地址為隧道終點地址 鏈路地址為可達(dá)路由器的鏈路地址 （ ）否則為不可達(dá) d 在線/離線的確定 IPv 使用子網(wǎng)掩碼確定 IPv 使用鄰居發(fā)現(xiàn)協(xié)議 兩者共同使用的是 如果目的地址是IPv 地址 則使用 RFC 比較兩者的掩碼 如果目的地址是IPv 兼容的IPv 地址 則使用低 位目的地址的子網(wǎng)掩碼比較 如果是 IPv 純地址 則使用鄰居發(fā)現(xiàn)協(xié)議 三 Linux下IPv 網(wǎng)絡(luò)研究實驗我們在研究了大量IPv 協(xié)議（主要的IPv RFC文檔）之后 進(jìn)行了一系列的IPv 研究實驗 現(xiàn)詳細(xì)敘述如下 ．Pv 研究實驗平臺的選擇在國內(nèi)有幾所大學(xué)已經(jīng)或正在進(jìn)行IPv 實驗研究 并且建立了CERNET IPv 實驗床 我們在與CERNET IPv 實驗床的老師和同學(xué)取得聯(lián)系并進(jìn)行了交流 實驗床網(wǎng)絡(luò)中心最初的組網(wǎng)是通過主機配置FreeBSD來完成的 年開始用的是FreeBSD 現(xiàn)在是FreeBSD 都有 此外有些科研人員也開始采用linux進(jìn)行實驗 路由器現(xiàn)在采用的是Nokia的IP 還有FreeBSD+Mrtd的主機 電子科大作為教育網(wǎng)西南地區(qū)的主節(jié)點 也得到了Nokia捐贈的IPv 路由器 在此基礎(chǔ)之上 我們通過分析比較研究各種操作系統(tǒng) 最后選定用linux作為IPv 主機和路由器研究實驗平臺 具體原因如下 A． Linux作為開放的操作系統(tǒng) 其原代碼完全公開 具有很強的靈活性 現(xiàn)在有很多自由軟件聯(lián)盟為Linux免費開發(fā)如件 故Linux具有很強的生命力和活力 而其他大部分由個別公司開發(fā)的操作系統(tǒng) 一方面原代碼不公開 無法根據(jù)自己的要求修改內(nèi)核 其公司的發(fā)展的興衰 很大程度上影響該操作系統(tǒng)的發(fā)展 B． Linux操作系統(tǒng)很先進(jìn) 一直跟蹤關(guān)注網(wǎng)絡(luò)的發(fā)展 用Linux組建Internet網(wǎng)絡(luò) 建立網(wǎng)站 進(jìn)行網(wǎng)絡(luò)開發(fā)研究 都是很好的選擇 并且其內(nèi)核從 開始 就已經(jīng)開始支持IPv 技術(shù)了 這等于就為我們提供了IPv 協(xié)議棧原代碼 我們可以利用其共享代碼做IPv 的研究開發(fā) ．Linux主機IPv 協(xié)議支持技術(shù)研究在選定了實驗平臺之后 我們就著手進(jìn)行一系列的IPv 實驗 主要針對在已大量安裝了IPv 的主機和路由器情況下 如何成功地兼容地升級到IPv 如何運用在IPv 主機和路由器上 與Ipv 主機和路由器成功互操作 以及如何建立配置IPv 主機和路由器 在進(jìn)行IPv 實驗之前 我們根據(jù)網(wǎng)上查詢資料及對Linux內(nèi)核分析 研究了如何建立IPv 主機 包括安裝協(xié)議棧 網(wǎng)絡(luò)工具及網(wǎng)絡(luò)程序 現(xiàn)以Redhat Linux為例 詳細(xì)說明其具體步驟如下 A．支持IPv 協(xié)議的新內(nèi)核的編譯要讓操作系統(tǒng)支持IPv 就要安裝IPv 協(xié)議棧 Redhat 的內(nèi)核為 版本 可支持IPv 但是安裝缺省不支持 由于協(xié)議棧在操作系統(tǒng)中是處于核心地位的 必須重新編譯新的內(nèi)核才能安裝上新的協(xié)議棧 其具體步驟如下 )以root身份登陸 進(jìn)入源碼所在的目錄 cd /usr/src/linux )運行 make clean 清除一些可能過期的中間代碼 ) 然后配置內(nèi)核選項 make menuconfig 或者 make xmenuconfig運行make menuconfig后 將下面的支持IPv 的選項選上 其他內(nèi)核選項請根據(jù)系統(tǒng)的具體情況作出符合系統(tǒng)的選擇 Code maturity level optionsPrompt for development and/or inplete code/drivers Yes Neorking optionsPacket socket yesUnix domain socketsyesTCP/IP neorkingyesThe IPv protocolyesIPv : enable EUI token format yesIPv : disable provider based address yes File systems/ procfilesy lishixinzhi/Article/program/Oracle/202311/17046
關(guān)于linux qos 實現(xiàn)機制的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗。專業(yè)提供云主機、虛擬主機、域名注冊、VPS主機、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
分享標(biāo)題：深入了解LinuxQoS的實現(xiàn)機制(linuxqos實現(xiàn)機制)
分享URL：http://m.5511xx.com/article/coddsjg.html
