本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon EBS I/O 特性和監控
在指定的磁碟區組態上,某些 I/O 特性會驅動 EBS 磁碟區的效能行為。
-
單SSD支援磁碟區、一般用途SSD (
gp2
和gp3
) 和佈建IOPSSSD (io1
和io2
),無論 I/O 操作是隨機還是循序,都能提供一致的效能。 -
單HDD支援磁碟區、輸送量最佳化HDD (
st1
) 和冷HDD (sc1
),只有在 I/O 操作大型且循序時,才能提供最佳效能。
若要了解 SSD 和 HDD 磁碟區如何在應用程式中執行,請務必了解磁碟區上的需求、可用的 IOPS 數量、完成 I/O 操作所需的時間,以及磁碟區的輸送量限制之間的連線。
IOPS
IOPS 是比 input/output operations per second. The operations are measured in KiB, and the underlying drive technology determines the maximum amount of data that a volume type counts as a single I/O. I/O size is capped at 256 KiB for SSD volumes and 1,024 KiB for HDD volumes because SSD volumes handle small or random 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 I/O 操作合併為單一 1,024 KiB I/O 操作。 | ||
8 個隨機 32 KiB I/O 操作 | 8 | Amazon EBS 會分別計算隨機 I/O 操作。 |
因此,當您建立支援 3,000 個 IOPS 的 SSD 後端磁碟區 (透過佈建 io1
或 io2
3,000 個 IOPS 的磁碟區、將gp2
磁碟區調整為 1,000 GiB 的大小,或使用磁碟gp3
區),並且將其連接至可提供足夠頻寬的 EBS 最佳化執行個體時,每秒最多可以傳輸 3,000 個 I/O 的資料,輸送量取決於 I/O 大小。
磁碟區佇列長度和延遲
磁碟區佇列長度是裝置的待處理 I/O 請求數目。延遲是 I/O 操作的 true end-to-end 用戶端時間,換句話說,從將 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
磁碟區具有 3,000 個IOPS的限制,而 250 MiB/s. If you are using a 256 KiB I/O size, your volume reaches its throughput limit at 1000 IOPS (1000 x 256 KiB = 250 MiB). For smaller I/O sizes (such as 16 KiB), this same volume can sustain 3,000 IOPS because the throughput is well below 250 MiB/s. (These examples assume that your volume's I/O的磁碟區輸送量限制未達到執行個體的輸送量限制。) 如需每個 EBS 磁碟區類型輸送量限制的詳細資訊,請參閱 Amazon EBS 磁碟區類型。
對於較小的 I/O 操作,您可能會看到從執行個體內部測量的 a higher-than-provisioned 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 最佳化執行個體 (或 Gb/s network connectivity) for optimal performance. Another possible cause for not experiencing the expected IOPS is that you are not driving enough I/O 磁碟區中包含 10 個 EBS 的執行個體。
使用 CloudWatch 監控 I/O 特性
您可以使用每個磁碟區的 CloudWatch 磁碟區指標來監控這些 I/O 特性。
監控停滯的 I/O
VolumeStalledIOCheck
會監控 EBS 磁碟區的狀態,以判斷磁碟區何時受損。指標是二進位值,會根據 EBS 磁碟區是否可以完成 I/O 操作,傳回 0
(通過) 或 1
(失敗) 狀態。
如果VolumeStalledIOCheck
指標失敗,您可以等待 AWS 解決問題,也可以採取動作,例如取代受影響的磁碟區,或停止和重新啟動磁碟區連接的執行個體。在大多數情況下,當此指標失敗時,EBS 會在幾分鐘內自動診斷並復原您的磁碟區。您可以使用 中的暫停 I/O 動作 AWS Fault Injection Service 來執行受控實驗,根據此指標測試您的架構和監控,以改善儲存故障的彈性。
監控磁碟區的 I/O 延遲
您可以使用 和 VolumeAvgWiteLatency
指標,分別監控 Amazon EBS 磁碟區讀取VolumeAvgReadLatency
和寫入操作的平均延遲。
如果您的 I/O 延遲高於您需要的延遲,請確定您的應用程式不會嘗試驅動超過您為磁碟區佈建的 IOPS 或輸送量。使用下列公式計算在特定期間內驅動至磁碟區的平均 IOPS 和輸送量,然後與磁碟區佈建的 IOPS 和輸送量進行比較。
Sum(VolumeReadOps) + Sum(VolumeWriteOps)
Estimated average IOPS in ops/s = ----------------------------------------
Period - Sum(VolumeIdleTime)
(Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / 1024
Estimated average throughput in KiB/s = -----------------------------------------------------
Period - Sum(VolumeIdleTime)
您也可以監控 VolumeIOPSExceededCheck
和 VolumeThroughputExceededCheck
指標,以判斷您的工作負載是否持續嘗試驅動 IOPS 或輸送量,而該輸送量高於您磁碟區的佈建效能。如果驅動的 IOPS 持續超過磁碟區佈建的 IOPS 效能,VolumeIOPSExceededCheck
指標會傳回 1
。如果驅動的輸送量持續超過磁碟區的佈建輸送量效能,VolumeThroughputExceededCheck
指標會傳回 1
。如果驅動的 IOPS 和輸送量在磁碟區的佈建效能內,則指標會傳回 0
。
如果您的應用程式需要的 IOPS 數量超過磁碟區可提供的數量,您應該考慮使用下列其中一項:
-
佈建足夠的 IOPS 以達到所需延遲的
gp3
io2
、 或io1
磁碟區 -
提供足夠基準 IOPS 效能的較大
gp2
磁碟區
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 CloudWatch 的 AmazonEBS 指標和 Nitro 型執行個體的 Amazon EBS 指標。
監控即時 I/O 效能統計資料
您可以存取連接至 Nitro 型 Amazon EBS 執行個體的 Amazon EC2 磁碟區的即時詳細效能統計資料。
您可以結合這些統計資料來衍生平均延遲和 IOPS,或檢查 I/O 操作是否已完成。您也可以檢視應用程式超過 EBS 磁碟區或連接執行個體佈建的 IOPS 或輸送量限制的總時間。透過追蹤這些統計資料隨時間增加,您可以識別是否需要增加佈建的 IOPS 或輸送量限制,以最佳化應用程式的效能。詳細的效能統計資料也包括讀取和寫入 I/O 操作的長條圖,透過追蹤在延遲頻帶內完成的 I/O 操作總數,提供 I/O 延遲的分佈。
如需詳細資訊,請參閱Amazon EBS 詳細效能統計資料。
相關資源
如需 Amazon EBS I/O 特性的詳細資訊,請參閱下列 re:Invent 簡報:Amazon EBS:Designing for Performance