6.4.3. Noop

/sys/block/sdX/queue tunables

add_random

在一些情況下，I/O 事件的負載對 /dev/random 的亂數集區的影響，是可以測量的。在這種情況下，將這個值設為零較佳。

max_sectors_kb

就預設值，可傳送給磁碟的最大請求大小為 512 KB。此微調選項可被使用來提升或降低這個值。最小值是以邏輯區塊大小所限制的；最大值則是以 max_hw_sectors_kb 限制。有些 SSD 在 I/O 大小超過了內部清除區塊大小時，效能會變差。在這種情況下，建議您將 max_hw_sectors_kb 微調成清除區塊的大小。您可透過使用一個例如 iozone 或是 aio-stress 的 I/O 產生程式來進行測試，並使用各種不同記錄大小（比方說由 512 位元組至 1 MB）。

nomerges

這個微調選項有助於除錯。大部分工作負載都能得益於合併需求（即使在更快的儲存裝置，例如 SSD 上亦然）。然而在一些情況下，例如想要知道後端儲存裝置的 IOPS 數據時，會想要停用合併功能，而不停用預先讀取或進行隨機讀取。

nr_requests

每個需求佇列都有可分配給每個讀、寫 I/O 的需求描述子的限制。預設上，這個數值是 128，表示在同一個時間內，在把程序放入睡眠狀態之前，佇列中可以有 128 組讀取、以及 128 組寫入。放入睡眠狀態的程序是下一個要試著分配需求的程序，並不一定是已分配所有可用需求的程序。

如果應用程式不適合延遲，那麼不妨降低需求佇列的 nr_requests 值，並限制儲存裝置的指令佇列深度至低的值（甚至可以低到 1），這樣一來回寫 I/O 就無法分配所有可用需求描述子，並以寫入 I/O 填滿整個裝置佇列。一旦 nr_requests 已分配，所有試圖進行 I/O 的其它程序會被放入睡眠狀態，以等待可用需求出現。這會讓事情變得公平，因為接下來需求會以輪詢方式分配（而不是讓單一程序快速地連續消耗所有需求）。請注意，在使用期限排程器或 noop 排程器時，這不會是問題，因為預設的 CFQ 配置會在這種情況下進行保護。

optimal_io_size

在一些情況下，下層的儲存裝置會回報最適合的 I/O 大小。這在軟、硬體 RAID 之間最常見，因為最適 I/O 大小正是磁條的大小。如果回報了這個值，應用程式應該會儘可能發出適用於最適 I/O 大小的多組對應。

read_ahead_kb

當應用程式從檔案或磁碟循序讀取資料時，作業系統會偵測到此一行為。在這種情況下，作業系統會使用智慧型預先讀取的演算法則，藉以從磁碟中讀取比使用者要求更多的資料。這樣一來，當下一個使用者試著讀取資料時，資料已經位於作業系統的分頁快取中。潛在的壞處是，作業系統可能會從磁碟讀取超過所需的資料，佔據太多分頁快取的空間，對記憶體使用量造成壓力。在這種情況下，太多程序都發生錯誤的預先讀取，會對記憶體造成壓力。

對於裝置對應（device mapper）的裝置，將 read_ahead_kb 增加至較大的值，例如 8192，是個好主意。這是因為裝置對應的裝置通常是由多個底層裝置所構成。將這個預設值（128 KB）乘以對應的裝置數量，是進行微調的適合起點。

rotational

傳統硬碟通常有著運轉的部件（例如轉盤）。然而 SSD 卻沒有。大部分 SSD 都標榜此一特性。然而，如果您發現有個裝置並不標榜此一特性，也許可以將此值手動設為 0；當停用此值時，I/O elevator 並不會使用降低搜尋時間的邏輯，因為在非運轉的裝置上進行搜尋，效能幾乎不會降低。

rq_affinity

發出 I/O 的 CPU 與完成 I/O 的 CPU 不一定是同一個。將 rq_affinity 設為 1 會導致 kernel 將完成 I/O 的動作，發至發出 I/O 的 CPU 上。這可以改善 CPU 資料快取的效能。