

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon EBS I/O 特性和監控
<a name="ebs-io-characteristics"></a>

在指定的磁碟區組態中，某些 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 操作之所需時間及磁碟區輸送量限制間的關聯性。

**Topics**
+ [IOPS](#ebs-io-iops)
+ [磁碟區佇列長度和延遲](#ebs-io-volume-queue)
+ [I/O 大小和磁碟區輸送量限制](#ebs-io-size-throughput-limits)
+ [使用 CloudWatch 監控 I/O 特性](#ebs-io-metrics)
+ [監控即時 I/O 效能統計資料](#monitor-io-nvme)
+ [相關資源](#ebs-io-resources)

## IOPS
<a name="ebs-io-iops"></a>

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 操作。下表顯示一些範例。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/ebs/latest/userguide/ebs-io-characteristics.html)

因此，當您建立支援 3，000 IOPS 的 SSD 支援磁碟區 （透過使用 3，000 IOPS 佈建 `io1`或 `io2`磁碟區、將`gp2`磁碟區調整為 1，000 GiB，或使用 磁碟`gp3`區），並且將其連接至可提供足夠頻寬的 EBS 最佳化執行個體時，每秒最多可以傳輸 3，000 I/O 的資料，輸送量取決於 I/O 大小。

## 磁碟區佇列長度和延遲
<a name="ebs-io-volume-queue"></a>

磁碟區佇列長度是裝置的待處理 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 延遲增加。為了達到最高一致性，磁碟區必須在一分鐘內維持每 1，000 個佈建 IOPS 的平均佇列深度 （四捨五入至最接近的整數） 為 1。例如，對於佈建 3，000 IOPS 的磁碟區，佇列深度平均值必須為 3。

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

## I/O 大小和磁碟區輸送量限制
<a name="ebs-io-size-throughput-limits"></a>

對於 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 磁碟區類型](ebs-volume-types.md)。

對於較小的 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 網路連線能力的執行個體) 以獲得最佳效能。未達到預期 IOPS 的另一個可能原因是您沒有為 EBS 磁碟區驅動足夠的 I/O。

## 使用 CloudWatch 監控 I/O 特性
<a name="ebs-io-metrics"></a>

您可以使用每個磁碟區的 [CloudWatch 磁碟區指標](using_cloudwatch_ebs.md#ebs-volume-metrics)來監控這些 I/O 特性。

**監控停滯的 I/O**  
`VolumeStalledIOCheck` 監視 EBS 磁碟區的狀態，以判斷磁碟區何時受損。此指標是二進位值，會根據 EBS 磁碟區是否能夠完成 I/O 作業而傳回 `0` (通過) 或 `1` (失敗) 狀態。

如果`VolumeStalledIOCheck`指標失敗，您可以等待 AWS 解決問題，也可以採取動作，例如取代受影響的磁碟區，或停止和重新啟動連接磁碟區的執行個體。在大多數情況下，當此指標失敗時，EBS 會在幾分鐘內自動診斷並復原磁碟區。您可以使用 中的[暫停 I/O](ebs-fis.md) 動作 AWS Fault Injection Service 來執行受控實驗，根據此指標測試您的架構和監控，以改善儲存故障的彈性。

**監控磁碟區的 I/O 延遲**  
您可以使用 和 `VolumeAvgWriteLatency`指標，分別監控 Amazon EBS 磁碟區讀取`VolumeAvgReadLatency`和寫入操作的平均延遲。您可以使用 中的[延遲注入](ebs-fis-latency-injection.md)動作 AWS Fault Injection Service 來執行受控實驗，根據此指標測試您的架構和監控，以改善儲存效能降級的彈性。

如果您的 I/O 延遲高於您的需求，請確定您的應用程式不會嘗試驅動超過您為磁碟區佈建的 IOPS 或輸送量。您可以使用 `VolumeAvgIOPS`和 `VolumeAvgThroughput`指標來監控一分鐘內驅動至磁碟區的平均 IOPS 和輸送量，然後將該值與磁碟區的佈建 IOPS 和輸送量進行比較。如果磁碟區在該分鐘內未驅動任何操作，則指標將報告零值 (`0`)。如果高 IOPS 或輸送量暴增的時間短於分鐘間隔，則磁碟區會發生微暴增，但平均 IOPS 和輸送量指標可能會報告您的效能低於磁碟區的佈建 IOPS 或調節限制。若要識別您的磁碟區是否在指定分鐘內遇到效能爆增，您可以使用 `VolumeIOPSExceededCheck`和 `VolumeThroughputExceededCheck`指標。您可以監控這些指標，以判斷工作負載是否持續嘗試在指定分鐘內驅動 IOPS 或輸送量大於您磁碟區的佈建效能。如果分鐘內任何秒的驅動 IOPS 持續超過磁碟區的佈建 IOPS 效能，`VolumeIOPSExceededCheck`指標會傳回 `1`。如果分鐘內任何秒的驅動輸送量一致超過磁碟區的佈建輸送量效能，`VolumeThroughputExceededCheck`指標會傳回 `1`。如果驅動 IOPS 和輸送量在您磁碟區的佈建效能內，指標會傳回 `0`。

如果應用程式需要的 IOPS 數目大於磁碟區可提供的 IOPS 數目，則應考慮使用下列其中一個方法：
+ 佈建有足夠 IOPS 以達到所需延遲的 `gp3`、`io2`、或 `io1` 磁碟區
+ 以較大的 `gp2` 磁碟區提供足夠的基準 IOPS 效能

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

**監控 `gp2`、 `st1`和 `sc1`磁碟區的爆量儲存貯體餘額**  
`BurstBalance` 將 `gp2`、`st1` 和 `sc1` 磁碟區的爆量儲存貯體額度顯示為剩餘額度的百分比。當爆量儲存貯體耗盡時，磁碟區 I/O (對於 `gp2` 磁碟區) 或磁碟區輸送量 (對於 `st1` 和 `sc1` 磁碟區) 將限制為基準。檢查 `BurstBalance` 值以確定您的磁碟區是否因此受到限制。如需可用 Amazon EBS 指標的完整清單，請參閱 [Amazon EBS 的 Amazon CloudWatch 指標](using_cloudwatch_ebs.md)和 [ Nitro 型執行個體的 Amazon EBS 指標](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ebs-metrics-nitro)。

## 監控即時 I/O 效能統計資料
<a name="monitor-io-nvme"></a>

您可以存取連接至 Nitro 型 Amazon EC2 執行個體之 Amazon EBS 磁碟區的即時詳細效能統計資料。

您可以結合這些統計資料來衍生平均延遲和 IOPS，或檢查 I/O 操作是否已完成。您也可以檢視應用程式超過 EBS 磁碟區或連接執行個體的佈建 IOPS 或輸送量限制的總時間量。透過追蹤這些統計資料隨著時間的增加，您可以識別是否需要增加佈建 IOPS 或輸送量限制，以最佳化應用程式的效能。詳細的效能統計資料也包含讀取和寫入 I/O 操作的長條圖，透過追蹤延遲頻帶內完成的 I/O 操作總數，提供 I/O 延遲的分佈。

如需詳細資訊，請參閱[Amazon EBS 詳細效能統計資料](nvme-detailed-performance-stats.md)。

## 相關資源
<a name="ebs-io-resources"></a>

如需 Amazon EBS I/O 特性的詳細資訊，請參閱下列 re:Invent 簡報：[Amazon EBS：專為效能設計](https://www.youtube.com/watch?v=2wKgha8CZ_w)。