IOPS 磁碟區佇列長度和延遲 I/O 大小和磁碟區輸送量限制使用 CloudWatch 監控 I/O 特性相關資源

I/O 特性與監控

在指定的磁碟區組態中，某些 I/O 特性會驅動 EBS 磁碟區的效能行為。SSD 支援的磁碟區 – 一般用途 SSD (gp2 和 gp3) 和佈建 IOPS SSD (io1 和 io2) – 無論 I/O 操作是隨機還是序列，都會提供一致效能。HDD 支援的磁碟區 – 輸送量最佳化 HDD (st1) 和冷 HDD (sc1) - 只有在 I/O 操作為大型且連續時才提供最佳效能。若要了解 SSD 和 HDD 磁碟區在您應用程式中的執行方式，必須先了解磁碟區需求、其可用 IOPS 數量、完成 I/O 操作之所需時間及磁碟區輸送量限制間的關聯性。

IOPS

IOPS 是每秒輸入/輸出操作的測量單位。操作的測量單位為 KiB，並且基礎磁碟機技術會決定磁碟區類型作為單一 I/O 時的最大資料量。SSD 磁碟區的 I/O 大小限制在 256 KiB，HDD 磁碟區則限制在 1,024 KiB，因為 SSD 磁碟區處理小型或隨機 I/O 比 HDD 磁碟區更有效率。

當小型 I/O 操作在物理上連續時，Amazon EBS 會嘗試將它們合併到單一 I/O 操作中，從而達到最大 I/O 大小。同樣，當 I/O 操作大於最大 I/O 大小時，Amazon EBS 會嘗試將其分割為較小的 I/O 操作。下表顯示一些範例。

容積類型	I/O 大小上限	您的應用程式的 I/O 操作	IOPS 數量	備註
SSD	256 KiB	1 x 1024 KiB I/O 操作	4 (1,024÷256=4)	Amazon EBS 將 1,024 I/O 操作分割成四個較小的 256 KiB 操作。
		8 個連續 32 KiB 輸入/輸出操作	1 (8x32=256)	Amazon EBS 將八個連續的 32 KiB I/O 操作合併為一個 256 KiB 操作。
		8 個隨機 32 KiB I/O 操作	8	Amazon EBS 分別計算隨機 I/O 操作。
HDD	1,024 KiB	1 x 1024 KiB I/O 操作	1	I/O 操作已經等於 I/O 大小上限。它不會被合併或分割。
		8 個連續 128 KiB 輸入/輸出操作	1 (8x128=1,024)	Amazon EBS 將八個連續的 128 KiB 輸入/輸出操作合併為一個 1,024 KiB 輸入/輸出操作。
		8 個隨機 32 KiB I/O 操作	8	Amazon EBS 分別計算隨機 I/O 操作。

因此，當建立支援 3,000 IOPS 的 SSD 支援磁碟區時 (透過以 3,000 IOPS 佈建 Provisioned IOPS SSD 磁碟區或以 1,000 GiB 調整一般用途 SSD 磁碟區的大小)，然後將其連接至可提供足夠頻寬的 EBS 最佳化執行個體，您可以每秒傳輸多達 3,000 個 I/O 資料，其輸送量由 I/O 大小決定。

磁碟區佇列長度和延遲

磁碟區佇列長度是裝置的待處理 I/O 請求數目。延遲是 I/O 操作用戶端的端對端真正時間，換句話說，是將 I/O 傳送到 EBS 以及從 EBS 接收 I/O 讀取或寫入完成之間的認知所經過之時間。佇列長度必須使用 I/O 大小和延遲來正確地校準，以避免訪客作業系統或連結到 EBS 的網路上造成瓶頸。

最佳佇列長度因每個工作負載而異，取決於特定應用程式對 IOPS 和延遲的敏感度。如果您的工作負載未提供足夠的 I/O 請求來充分利用 EBS 磁碟區的可用效能，那麼您的磁碟區可能無法提供已佈建之 IOPS 或輸送量。

交易密集型應用程式對增加的 I/O 延遲非常敏感，非常適合 SSD 支援的磁碟區。您可以透過保持較低的佇列長度和較高磁碟區可用之 IOPS，來保持較高的 IOPS，同時保持低延遲。持續將更多 IOPS 驅動至可用的磁碟區上可能會導致 I/O 延遲增加。

輸送量密集型應用程式對增加的 I/O 延遲較不敏感，非常適合 HDD 支援的磁碟區。您可以透過在執行大型序列 I/O 時保持較高的佇列長度，來保持 HDD 支援之磁碟區的高輸送量。

I/O 大小和磁碟區輸送量限制

對於 SSD 支援的磁碟區，如果您的 I/O 大小非常大，則可能會經歷比您佈建數目更少的 IOPS，因為您正達到磁碟區的輸送量限制。例如，具有可用爆量額度的 1,000 GiB 以下的 gp2 磁碟區，其 IOPS 限制為 3,000，磁碟區的輸送量限制為 250 MiB/秒。如果您使用 256 KiB I/O 大小，則您的磁碟區將達到 1000 IOPS (1000 x 256 KiB = 250 MiB) 時的輸送量限制。對於較小的 I/O 大小 (如 16 KiB)，同樣的磁碟區可以維持 3,000 IOPS，因為輸送量遠低於 250 MiB/秒。(這些範例假設您的磁碟區 I/O 未達到執行個體輸送量限制。) 如需每個 EBS 磁碟區類型之輸送量限制的詳細資訊，請參閱 Amazon EBS 磁碟區類型。

對於較小的 I/O 操作，您可能會看到從執行個體內部測量之 IOPS 值高於所佈建的值。當執行個體作業系統將小型 I/O 操作合併至更大的操作並將其傳遞給 Amazon EBS 之前，會發生此情況。

如果您的工作負載在 HDD 支援的 st1 和 sc1 磁碟區上使用序列 I/O，則從執行個體內測得的 IOPS 數目可能會高於預期。當執行個體作業系統合併序列 I/O 並以 1,024 KiB 大小單位來計數時，會發生此情況。如果您的工作負載使用小型或隨機 I/O，則輸送量可能會低於您的預期。這是因為我們將每個隨機、非序列 I/O 計入 IOPS 總量，這可能會導致您比預期還更早達到磁碟區的 IOPS 限制。

重要

無論您的 EBS 磁碟區類型是什麼，如果在您的組態中沒有達到預期的 IOPS 或輸送量，請確認您的 EC2 執行個體頻寬並非限制因素。您應一律使用最新的 EBS 最佳化執行個體 (或包含 10 Gb/s 網路連線能力的執行個體) 以獲得最佳效能。如需詳細資訊，請參閱 Amazon EBS – 最佳化執行個體。未達到預期 IOPS 的另一個可能原因是您沒有為 EBS 磁碟區驅動足夠的 I/O。

使用 CloudWatch 監控 I/O 特性

您可以使用每個磁碟區的 CloudWatch 磁碟區指標來監控這些 I/O 特性。要考慮的重要指標包含下列項目：

BurstBalance
VolumeReadBytes
VolumeWriteBytes
VolumeReadOps
VolumeWriteOps
VolumeQueueLength

BurstBalance 將 gp2、st1 和 sc1 磁碟區的爆量儲存貯體額度顯示為剩餘額度的百分比。當爆量儲存貯體耗盡時，磁碟區 I/O (對於 gp2 磁碟區) 或磁碟區輸送量 (對於 st1 和 sc1 磁碟區) 將限制為基準。檢查 BurstBalance 值以確定您的磁碟區是否因此受到限制。如需可用 Amazon EBS 指標的完整清單，請參閱 Amazon EBS 指標和 Nitro 型執行個體的 Amazon EBS 指標。

HDD 支援的 st1 和 sc1 磁碟區設計為最大限度利用 1,024 KiB 最大 I/O 大小的工作負載效能。若要確定您的磁碟區之平均 I/O 大小，請將 VolumeWriteBytes 除以 VolumeWriteOps。同樣的計算方式也可套用至讀取操作。如果平均 I/O 大小低於 64 KiB，則增加傳送到 st1 或 sc1 磁碟區的 I/O 操作之大小應可提高效能。

注意

如果平均 I/O 大小為 44 KiB 或接近，您可能正在沒有間接描述項的支援下使用執行個體或核心。任何 Linux 核心 3.8 及更新版本都具備此支援，如同任何最新執行個體。

如果 I/O 延遲高於您的要求，請檢查 VolumeQueueLength 以確保應用程式不會嘗試驅動比您所佈建更多的 IOPS。如果應用程式需要的 IOPS 數目大於磁碟區可提供的 IOPS 數目，則應考慮使用下列其中一個方法：

以較大的 gp2 磁碟區提供足夠的基準 IOPS 效能
佈建有足夠 IOPS 以達到所需延遲的 gp3、io1、或 io2 磁碟區