適用於： ✔️ Linux VM ✔️ Windows VM ✔️ 彈性擴展集 ✔️ 統一擴展集
本文提供使用 Azure 進階記憶體建置高效能應用程式的指導方針。 您可以使用本檔中提供的指示，結合應用程式所使用的技術適用的效能最佳做法。 為了說明指導方針，我們在本檔中使用在進階記憶體上執行的 SQL Server 作為範例。
雖然我們處理本文中儲存層的效能案例，但您需要優化應用層。 例如，如果您要在進階記憶體上裝載 SharePoint 伺服器陣列，您可以使用本文中的 SQL Server 範例來優化資料庫伺服器。 您也可以將 SharePoint 伺服器陣列的網頁伺服器和應用程式伺服器優化，以獲得最佳效能。
本文可協助您回答下列有關優化進階記憶體上應用程式效能的常見問題：
- 如何測量應用程式效能？
- 為什麼您看不到預期的高效能？
- 哪些因素會影響您在進階記憶體上的應用程式效能？
- 這些因素如何影響應用程式在進階記憶體上的效能？
- 如何針對每秒的輸入/輸出作業 （IOPS）、頻寬和延遲進行優化？
我們特別針對進階記憶體提供這些指導方針，因為進階記憶體上執行的工作負載對效能高度敏感。 我們會在適當時提供範例。 您也可以將其中一些指導方針套用至使用標準記憶體磁碟在基礎結構即服務 （IaaS） VM 上執行的應用程式。
備註
有時候磁碟效能問題似乎是網路瓶頸。 在這些情況下，您應該將 網路效能優化。
如果您想要對磁碟進行效能評定，請參閱下列文章：
- 針對 Linux： 在 Azure 磁碟記憶體上對您的應用程式進行效能評定
- 針對 Windows： 對磁碟進行效能評定
如果您的 VM 支援加速網路功能，請確定它已啟用。 如果未啟用，您可以在 Windows 和Linux 上已部署的 VM 上啟用它。
開始之前，如果您不熟悉進階記憶體，請先閱讀 選取適用於IaaS VM 的 Azure 磁碟類型 ，以及 進階分頁 Blob 記憶體帳戶的延展性目標。
應用程式效能指標
我們會使用效能指標來評估應用程式是否執行良好，例如：
- 應用程式處理使用者要求的速度。
- 應用程式每次請求處理的資料量。
- 應用程式在特定時間內處理的要求數目。
- 在提交要求之後，用戶必須等候取得回應的時間長度。
這些效能指標的技術詞彙為 IOPS、輸送量或頻寬，以及延遲。
在本節中，我們會討論進階記憶體內容中的常見效能指標。 在 磁碟的效能應用程式檢查清單一節中，您會瞭解如何測量應用程式的這些效能指標。 稍後在 優化應用程式效能中，您將了解影響這些效能指標和建議的因素，以將其優化。
IOPS
IOPS 是應用程式在一秒內傳送至記憶體磁碟的要求數目。 輸入/輸出作業可以是讀取或寫入、循序或隨機。 在線事務處理 （OLTP） 應用程式，例如在線零售網站，必須立即處理許多並行使用者要求。 使用者要求是插入和更新密集型資料庫交易，應用程式必須快速處理這些交易。 因此，OLTP 應用程式需要非常高的 IOPS。
OLTP 應用程式會處理數百萬個小型和隨機 I/O 要求。 如果您有這類應用程式，您必須設計應用程式基礎結構以優化 IOPS。 如需要考慮取得高 IOPS 之所有因素的詳細資訊，請參閱 優化應用程式效能。
當您將進階記憶體磁碟連結至高延展性 VM 時，Azure 會根據磁碟規格為您布建保證的 IOPS 數目。 例如，P50 磁碟提供 7,500 IOPS。 每個高延展性 VM 大小也有可維持的特定 IOPS 限制。 例如，標準 GS5 VM 有 80,000 個 IOPS 限制。
吞吐量
輸送量或頻寬是應用程式以指定間隔傳送至記憶體磁碟的數據量。 如果您的應用程式執行具有大型 I/O 單位大小的輸入/輸出作業，則需要高輸送量。 數據倉儲應用程式往往會發出以掃描為主的大量作業，每次存取大量數據，且通常會執行批量作業。 換句話說，這類應用程式需要更高的輸送量。 如果您有這類應用程式，您必須設計其基礎結構以優化輸送量。 在下一節中，我們會討論您必須調整以達到此優化的因素。
當您將進階記憶體磁碟連結至高階 VM 時，Azure 會根據該磁碟規格布建輸送量。 例如，P50 磁碟會配置 250 MB/秒的磁碟吞吐量。 每個高效能 VM 大小也有其可維持的特定吞吐量限制。 例如，標準 GS5 VM 的最大輸送量為 2,000 MB/秒。
輸送量與 IOPS 之間有關聯，如下列公式所示。
請務必判斷應用程式所需的最佳輸送量和 IOPS 值。 當您嘗試優化其中一個時，另一個也會受到影響。 如需優化 IOPS 和輸送量的詳細資訊，請參閱 優化應用程式效能。
延遲
延遲是應用程式接收單一要求、將它傳送至記憶體磁碟，以及將回應傳送給用戶端所花費的時間。 除了 IOPS 和輸送量，延遲也是應用程式效能的一個重要量值。 進階記憶體磁碟的延遲是擷取要求資訊並傳回應用程式所需的時間。 進階記憶體提供持續低延遲。 進階磁碟的設計目的是為大部分 I/O 作業提供單一位數的毫秒延遲。 如果您在進階記憶體磁碟上啟用 ReadOnly 主機快取，可以降低讀取延遲。 如需磁碟快取的詳細資訊，請參閱 磁碟快取。
當您將應用程式優化以取得較高的 IOPS 和輸送量時，它會影響應用程式的延遲。 微調應用程式效能之後，請評估應用程式的延遲，以避免非預期的高延遲行為。
受控磁碟上的某些控制平面作業可能會將磁碟從一個儲存位置移至另一個存放位置。 藉由在背景中複製數據來協調磁碟在儲存位置之間的移動，這可能需要數小時才能完成。 一般而言，所需時間會根據硬碟中的數據量而定，通常小於24小時。 在此期間，您的應用程式可能會經歷高於一般讀取延遲，因為某些讀取可能會重新導向至原始位置，而且需要較長的時間才能完成。
在背景複製期間，對大多數磁碟類型的寫入延遲沒有任何影響。 針對進階 SSD v2 和 Ultra 磁碟，如果磁碟有 4K 扇區大小，則會有較高的讀取延遲。 如果磁碟有 512e 扇區大小，則其讀取和寫入延遲較高。
下列控制平面作業可能會在儲存位置之間移動磁碟，並導致延遲增加：
- 更新記憶體類型。
- 將磁碟從一部 VM 卸載並安裝至另一部 VM。
- 從 VHD 建立受控磁碟。
- 從快照建立管理磁碟。
- 將非受控磁碟轉換為受控磁碟。
磁碟的效能應用程式檢查清單
設計在進階記憶體上執行的高效能應用程式的第一個步驟是瞭解應用程式的效能需求。 收集效能需求之後，您可以將應用程式優化，以達到最佳效能。
在上一節中，我們解釋了常見的效能指標：IOPS、輸送量和延遲。 您必須識別哪些效能指針對您的應用程式至關重要，才能提供所需的用戶體驗。 例如，高 IOPS 對 OLTP 應用程式而言，在一秒內處理數百萬筆交易最重要。 高吞吐量對於處理大量資料的資料倉儲應用來說至關重要。 極低的延遲對於即時視訊串流網站等即時應用程式而言非常重要。
接下來，測量應用程式在整個存留期內的最大效能需求。 使用下列範例檢查清單作為起點。 記錄一般、尖峰和離班工作負載期間的最大效能需求。 藉由識別所有工作負載層級的需求，您可以判斷應用程式的整體效能需求。
例如，電子商務網站的一般工作負載是它在一年中大部分天數內提供的交易。 網站的尖峰工作負載是它在假日季節或特別銷售活動期間提供的交易。 在有限的時間內，尖峰負載通常會發生，但這可能需要您的應用程式將其正常運作擴展到兩倍或更多。 瞭解50百分位數、90百分位數和99個百分位數需求。 這項資訊有助於篩選出效能需求中的任何極端值，而且您可以將精力集中在優化正確的值上。
應用程式效能需求檢查清單
| 效能需求 | 50 百分位數 | 90 百分位數 | 99 百分位數 |
|---|---|---|---|
| 每秒交易數上限 | |||
| % 讀取作業 | |||
| % 寫入作業 | |||
| % 隨機運算 | |||
| % 循序作業 | |||
| I/O 要求封包 | |||
| 平均輸送量 | |||
| 輸送量上限 | |||
| 最小延遲 | |||
| 平均延遲 | |||
| 最大中央處理器 | |||
| 平均 CPU | |||
| 記憶體上限 | |||
| 平均記憶體 | |||
| 佇列深度 |
備註
請考慮根據應用程式的預期未來成長來調整這些數位。 事先規劃成長是個好主意，因為稍後更難變更基礎結構以改善效能。
如果您有現有的應用程式並想要移至進階記憶體，請先建置現有應用程式的先前檢查清單。 然後，在進階記憶體上建置應用程式的原型，並根據 優化應用程式效能中所述的指導方針來設計應用程式。 下一篇文章說明可用來收集效能測量的工具。
用來測量應用程式效能需求的計數器
測量應用程式效能需求的最佳方式是使用 PerfMon伺服器作業系統所提供的監視工具。 您可以在 Windows 上使用 PerfMon，在 Linux 上使用 iostat。 這些工具會擷取與上一節所說明之每個指標對應的計數。 當您的應用程式執行其正常、尖峰和離時工作負載時，您必須擷取這些計數器的值。
計數器 PerfMon 適用於伺服器的處理器、記憶體，以及每個邏輯磁碟和實體磁碟。 當您搭配 VM 使用進階記憶體磁碟時，實體磁碟計數器會針對每個進階記憶體磁碟，而邏輯磁碟計數器則適用於在進階記憶體磁碟上建立的每個磁碟區。 您必須擷取裝載應用程式工作負載之磁碟的值。 如果邏輯和實體磁碟之間有一對一對應，您可以參考實體磁碟計數器。 否則，請參閱邏輯磁碟計數器。
在 Linux 上 iostat ，命令會產生 CPU 和磁碟使用率報告。 磁碟使用率報告會提供每個實體裝置或磁碟分區的統計數據。 如果您有資料庫伺服器及其數據和記錄在不同的磁碟上，請針對這兩個磁碟收集此數據。 下表描述磁碟、處理器和記憶體的計數器。
| 計數器 | 說明 | 效能監視器 (PerfMon) | iostat |
|---|---|---|---|
| IOPS 或交易/秒 | 向記憶體磁碟發出的 I/O 要求數目/秒 | 磁碟讀取次數/秒 磁碟每秒寫入次數 |
tps r/s w/s |
| 磁碟讀取和寫入 | 磁碟上執行的讀取和寫入作業 % | % 磁碟讀取時間 % 磁碟寫入時間 |
r/s w/s |
| 吞吐量 | 讀取或寫入磁碟的數據量/秒 | 磁碟讀取位元組/秒 磁碟寫入位元組/秒 |
kB_read/s kB_wrtn/秒 |
| 延遲 | 完成磁碟 I/O 要求的總時間 | 平均磁碟每次讀取時間（秒） 平均磁碟寫入時間 |
await svctm |
| I/O 大小 | 發出給儲存體磁碟的 I/O 要求大小 | 平均每次讀取的磁碟位元組數 平均磁碟位元組/寫入 |
avgrq-sz |
| 佇列深度 | 等候讀取或寫入記憶體磁碟的未處理 I/O 要求數目 | 目前的磁碟佇列長度 | avgqu-sz |
| 記憶體上限 | 順利執行應用程式所需的記憶體數量 | ％ 已認可的使用位元數 | 使用 vmstat |
| 最大中央處理器 | 順利執行應用程式所需的CPU數量 | % 處理器時間 | %util |
將應用程式效能優化
影響在進階記憶體上執行之應用程式效能的主要因素是 I/O 要求、VM 大小、磁碟大小、磁碟數目、磁碟快取、多線程和佇列深度。 您可以使用系統提供的旋鈕來控制其中一些因素。
大部分的應用程式可能無法讓您選擇直接改變 I/O 大小和佇列深度。 例如，如果您使用 SQL Server，則無法選擇 I/O 大小和佇列深度。 SQL Server 會選擇最佳的 I/O 大小和佇列深度值，以獲得最佳效能。 請務必瞭解這兩種因素對應用程式效能的影響，以便布建適當的資源以符合效能需求。
在本節中，請參閱您建立的應用程式需求檢查清單，以識別優化應用程式效能所需的量。 根據檢查清單，您可以判斷本節中您需要微調的因素。
若要見證每個因素對應用程式效能的影響，請在應用程式設定上執行效能評定工具。 如需在 Windows 和 Linux VM 上執行一般基準檢驗工具的步驟，請參閱本文件結尾的基準檢驗文章。
一目了然地優化 IOPS、輸送量和延遲
下表摘要說明效能因素和優化 IOPS、輸送量和延遲所需的步驟。 本摘要後面的各節將更深入地描述每個因素。
如需 VM 大小和每種 VM 類型可用 IOPS、輸送量和延遲的詳細資訊，請參閱 Azure 中虛擬機的大小。
| 效能因素 | IOPS | 吞吐量 | 延遲 |
|---|---|---|---|
| 範例案例 | 企業 OLTP 應用程式每秒需要非常高的交易率。 | 企業數據倉儲應用程式會處理大量數據。 | 近乎即時的應用程式需要立即回應使用者要求，例如在線遊戲。 |
| 效能因素 | |||
| I/O 大小 | 較小的 I/O 大小會產生較高的 IOPS。 | 較大的 I/O 大小會產生較高的輸送量。 | |
| VM 大小 | 使用 IOPS 大於應用程式需求的 VM 大小。 | 使用輸送量限制大於應用程式需求的 VM 大小。 | 使用調整限制大於應用程式需求的 VM 大小。 |
| 磁碟大小 | 使用 IOPS 大於應用程式需求的磁碟大小。 | 使用輸送量限制大於應用程式需求的磁碟大小。 | 使用調整限制大於應用程式需求的磁碟大小。 |
| VM 和磁碟規模限制 | 所選 VM 大小的 IOPS 限制應該大於所連結記憶體磁碟所驅動的總 IOPS。 | 所選 VM 大小的輸送量限制應該大於高階儲存磁碟所承載的輸送量總計。 | 所選 VM 大小的規模限制必須大於所附加高級儲存磁碟的總規模限制。 |
| 磁碟快取 | 在具有大量讀取作業的進階記憶體磁碟上啟用 ReadOnly 快取，以取得較高的讀取 IOPS。 | 在具有大量讀取作業的進階記憶體磁碟上啟用 ReadOnly 快取，以取得非常低的讀取延遲。 | |
| 磁碟等量分割 | 使用多個磁碟並串接在一起，可結合產生較高的 IOPS 和輸送量限制。 每個 VM 的合併限制應高於連結進階磁碟的合併限制。 | ||
| 條紋大小 | 在 OLTP 應用程式中，隨機小型 I/O 模式使用較小的等量大小。 例如，SQL Server OLTP 應用程式使用 64-KB 等量大小。 | 在資料倉儲應用程式中，循序大型 I/O 模式使用較大的等量大小。 例如，針對 SQL Server 數據倉儲應用程式使用 256-KB 的條帶大小。 | |
| 多線程 | 使用多線程將較高的要求推送至進階記憶體，以導致較高的 IOPS 和輸送量。 例如，在 SQL Server 上，設定高 MAXDOP 值，將更多 CPU 配置給 SQL Server。 | ||
| 佇列深度 | 較大的佇列深度會產生較高的 IOPS。 | 較大的佇列深度會產生較高的輸送量。 | 較小的佇列深度會產生較低的延遲。 |
I/O 要求的本質
I/O 要求是應用程式正在執行的輸入/輸出作業單位。 識別 I/O 要求的本質、隨機或循序、讀取或寫入、小型或大型，可協助您判斷應用程式的效能需求。 瞭解 I/O 要求的本質對於在設計應用程式基礎結構時做出正確的決策至關重要。 I/O 必須分布均勻，才能達到最佳效能。
I/O 大小是其中一個更重要的因素。 I/O 大小是應用程式所產生的輸入/輸出作業要求大小。 I/O 大小會大幅影響效能，特別是在應用程式可達到的 IOPS 和頻寬上。 下列公式顯示 IOPS、I/O 大小和頻寬/輸送量之間的關聯性。
有些應用程式可讓您改變其 I/O 大小，而有些應用程式則不允許。 例如，SQL Server 會判斷最佳的 I/O 大小本身，而且不會為使用者提供任何旋鈕來變更它。 另一方面，Oracle 提供稱為 DB_BLOCK_SIZE 的參數，可用來設定資料庫的 I/O 要求大小。
如果您使用的應用程式不允許變更 I/O 大小，請使用本文中的指導方針來優化與應用程式最相關的效能 KPI。 例如：
- OLTP 應用程式會產生數百萬個小型和隨機 I/O 要求。 若要處理這些類型的 I/O 要求，您必須設計應用程式基礎結構以取得較高的 IOPS。
- 數據倉儲應用程式會產生大型且循序的 I/O 要求。 若要處理這些類型的 I/O 要求，您必須設計應用程式基礎結構以取得更高的頻寬或輸送量。
如果您使用的應用程式可讓您變更 I/O 大小，除了參考其他效能指導方針，請利用此基本原則來決定 I/O 大小：
- 較小的 I/O 大小，以取得較高的 IOPS。 例如，對於 OLTP 應用程式來說，可能是 8 KB。
- 較大的 I/O 大小，以取得更高的頻寬/輸送量。 例如，資料倉儲應用程式使用 1024 KB。
以下是如何計算應用程式的 IOPS 和輸送量/頻寬的範例。
請考慮使用 P30 磁碟的應用程式。 P30 磁碟可達到的最大 IOPS 和輸送量/頻寬分別為 5,000 IOPS 和 200 MB/秒。 如果您的應用程式需要 P30 磁碟的最大 IOPS，而且您使用的 I/O 大小較小，例如 8 KB，則產生的頻寬為 40 MB/秒。如果您的應用程式需要 P30 磁碟的最大輸送量/頻寬，而且您使用較大的 I/O 大小，例如 1,024 KB，則產生的 IOPS 較少，例如 200 IOPS。
調整 I/O 大小，使其符合應用程式的 IOPS 和輸送量/頻寬需求。 下表摘要說明 P30 磁碟的不同 I/O 大小及其對應的 IOPS 和輸送量。
| 應用程式需求 | I/O 大小 | IOPS | 輸送量/带寬 |
|---|---|---|---|
| IOPS 上限 | 8 KB | 5,000 | 40 MB/秒 |
| 輸送量上限 | 1,024 KB | 200 | 200 MB/秒 |
| 最大輸送量 + 高 IOPS | 64 KB | 3,200 | 200 MB/秒 |
| 最大 IOPS + 高輸送量 | 32 KB | 5,000 | 160 MB/秒 |
若要取得高於單一進階記憶體磁碟最大值的 IOPS 和頻寬，請使用多個等量分割的進階磁碟。 例如，將兩個 P30 磁碟做磁碟分條，以取得總計 10,000 IOPS 的效能或總計 400 MB/秒的吞吐量。如下一節所述，您必須使用支援總計磁碟 IOPS 和吞吐量的 VM 大小。
備註
當您增加 IOPS 或輸送量時，另一個也會增加。 當您增加其中一個磁碟或 VM 時，請確定您未達到磁碟或 VM 的輸送量或 IOPS 限制。
若要見證 I/O 大小對應用程式效能的影響，您可以在 VM 和磁碟上執行效能評定工具。 建立多個測試回合，並針對每個回合使用不同的 I/O 大小來查看效果。 如需詳細資訊，請參閱本文件結尾的基準檢驗文章。
高延展性 VM 大小
當您開始設計應用程式時，要做的第一件事之一是選擇 VM 來裝載您的應用程式。 進階記憶體隨附大規模 VM 大小，可執行需要較高計算能力和高本機磁碟 I/O 效能的應用程式。 這些 VM 提供更快的處理器、較高的記憶體與核心比率，以及本機磁碟的固態硬碟 （SSD）。 支援進階記憶體的高階 VM 範例包括 DS 和 GS 系列 VM。
大規模的 VM 有多種不同尺寸，配有不同數量的 CPU 核心、記憶體、作業系統，以及暫存磁碟大小。 每個 VM 大小也有您可以連結至 VM 的數據磁碟數目上限。 所選的 VM 大小會影響應用程式可用的處理、記憶體和記憶體容量。 它也會影響計算和記憶體成本。 例如，下列規格適用於DS系列和 GS 系列中最大的 VM 大小。
| VM 大小 | CPU 核心 | 記憶體 | VM 磁碟大小 | 數據磁碟上限 | 快取大小 | IOPS | 頻寬快取 I/O 限制 |
|---|---|---|---|---|---|---|---|
| 標準 DS14 | 16 | 112 GB | 作業系統 = 1,023 GB 本機 SSD = 224 GB |
32 | 576 GB | 50,000 IOPS 512 MB/秒 |
4,000 IOPS 和 33 MB/秒 |
| Standard_GS5 | 32 | 448 GB | 作業系統 = 1,023 GB 本機 SSD = 896 GB |
64 | 4224 GB | 80,000 IOPS 2,000 MB/秒 |
5,000 IOPS 和 50 MB/秒 |
若要檢視所有可用 Azure VM 大小的完整清單，請參閱 Azure 中虛擬機的大小。 選擇一個 VM 大小，可符合並調整至您所需的應用程式效能需求。 選擇 VM 大小時，請將下列重要因素一併納入考量。
規模限制
每個 VM 和每個磁碟的最大 IOPS 限制不同，彼此獨立。 請確定應用程式在 VM 及它連接的高階磁碟的限制內推動 IOPS。 否則，應用程式效能會發生節流現象。
例如，假設應用程式需求上限為 4,000 IOPS。 若要達到此層級，您可以在 DS1 VM 上佈建 P30 磁碟。 P30 磁碟最多可提供 5,000 IOPS。 不過，DS1 VM 限制為 3,200 IOPS。 因此，應用程式效能會受限於 VM 限制為 3,200 IOPS，而效能會降低。 若要避免這種情況，請選擇符合應用程式需求的 VM 和磁碟大小。
作業成本
在許多情況下，使用進階記憶體的整體作業成本可能低於使用標準記憶體。
例如，假設應用程式需要 16,000 IOPS。 若要達到此效能，您需要Standard_D14 Azure IaaS VM，其可使用 32 個標準記憶體 1 TB 磁碟來提供最大 IOPS 16,000。 每個 1 TB 的標準記憶體磁碟最多可以達到 500 IOPS。
- 此 VM 每月的估計成本為 $1,570。
- 32 個標準記憶體磁碟的每月成本為 $1,638。
- 估計每月總成本為 3,208 美元。
如果您在進階記憶體上裝載相同的應用程式，則需要較小的 VM 大小和較少的進階記憶體磁碟，進而降低整體成本。 Standard_DS13 VM 可以使用四個 P30 磁碟來滿足 16,000 IOPS 需求。 DS13 VM 的 IOPS 上限為 25,600，而每個 P30 磁碟的 IOPS 上限為 5,000。 整體而言，此設定可以達到5,000 x 4 = 20,000 IOPS。
- 此 VM 每月的估計成本為 $1,003。
- 四個 P30 進階記憶體磁碟的每月成本為 $544.34。
- 估計每月總成本為 $1,544 美元。
下表摘要說明此案例的標準和進階記憶體成本明細。
| 每個月的成本 | 標準 | 高級 |
|---|---|---|
| 每月的 VM 成本 | $1,570.58 （Standard_D14） | $1,003.66 （Standard_DS13） |
| 每個月磁碟的成本 | $1,638.40 （32 x 1 TB 磁盘） | $544.34 （4 x P30 磁碟） |
| 每月整體成本 | $3,208.98 | $1,544.34 |
Linux 發行版
使用進階記憶體時，您會為執行 Windows 和 Linux 的 VM 取得相同的效能層級。 我們支援許多不同版本的Linux發行版。 如需詳細資訊，請參閱 在 Azure 上獲得認可的 Linux 散發套件。
不同的發行版更適合不同類型的工作負載。 根據工作負載執行的發行版本不同，您會看到不同的性能階級。 使用您的應用程式測試各個 Linux 發行版，並選擇最適合的版本。
當您使用進階記憶體執行 Linux 時，請檢查有關必要驅動程式的最新更新，以確保高效能。
進階記憶體磁碟大小
進階記憶體提供各種大小，因此您可以選擇最符合您需求的記憶體。 每個磁碟大小都有不同的 IOPS、頻寬和記憶體規模限制。 根據應用程式需求和大規模的 VM 大小，選擇正確的進階記憶體磁碟大小。 下表顯示磁碟大小及其功能。 P4、P6、P15、P60、P70 和 P80 大小目前僅支援受控磁碟。
| 進階 SSD 的大小 | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 磁碟大小 (以 GiB 為單位) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| 每個磁碟的基本佈建 IOPS | 120 | 120 | 120 | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
| **每個磁碟的擴充佈建 IOPS | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | 8,000 | 16,000 | 20,000 | 20,000 | 20,000 | 20,000 |
| 每個磁碟的基礎佈建吞吐量 | 25 MB/秒 | 25 MB/秒 | 25 MB/秒 | 25 MB/秒 | 50 MB/秒 | 100 MB/秒 | 125 MB/秒 | 150 MB/秒 | 200 MB/秒 | 250 MB/秒 | 250 MB/秒 | 500 MB/秒 | 750 MB/秒 | 900 MB/秒 |
| **每個磁碟的擴充佈建輸送量 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | 300 MB/秒 | 600 MB/秒 | 900 MB/秒 | 900 MB/秒 | 900 MB/秒 | 900 MB/秒 |
| 每一磁碟的 IOPS 高載上限 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| 每個磁碟的最大突發吞吐量 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* |
| 最大突發持續時間 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 30 分鐘 | 無限制* | 無限制* | 無限制* | 無限制* | 無限制* | 無限制* |
| 符合保留資格 | 否 | 否 | 否 | 否 | 否 | 否 | 否 | 否 | 是，最多一年 | 是，最多一年 | 是，最多一年 | 是，最多一年 | 是，最多一年 | 是，最多一年 |
*僅適用於已啟用隨選高載的磁碟。
** 僅適用於已啟用效能加強型的磁碟。
您選擇的磁碟數目取決於所選的磁碟大小。 您可以使用單一 P50 磁碟或多個 P10 磁碟來符合您的應用程式需求。 在您做出選擇時，請考慮這裡所列的考量因素。
規模限制 （IOPS 和吞吐量）
每個進階磁碟大小的 IOPS 和輸送量限制都不同，與 VM 調整限制無關。 請確定來自磁碟的 IOPS 和輸送量總計符合所選 VM 大小的縮放限制。
例如，如果應用程式需求上限為 250 MB/秒的輸送量，而您使用 DS4 VM 搭配單一 P30 磁碟，DS4 VM 最多可提供 256 MB/秒的輸送量。 不過，單一 P30 磁碟的輸送量限製為 200 MB/秒。因此，應用程式會因為磁碟限制而限制在 200 MB/秒。 若要克服此限制，請將多個數據磁碟布建至 VM，或將您的磁碟大小調整為 P40 或 P50。
備註
快取所提供的讀取不會包含在磁碟 IOPS 和輸送量中，因此不會受限於磁碟限制。 對於每個 VM，快取有其個別的 IOPS 和輸送量限制。
例如，一開始您的讀取和寫入分別為 60 MB/秒和 40 MB/秒。 經過一段時間，快取已活絡，可服務越來越多的讀取。 然後，您可以從磁碟取得更高的寫入輸送量。
磁碟數目
藉由評估應用程式需求來判斷您需要的磁碟數目。 每個 VM 大小也會限制您可以連結至 VM 的磁碟數目。 一般而言，此數量是核心數目的兩倍。 請確定您選擇的 VM 大小可支援所需的磁碟數目。
請記住，相較於標準記憶體磁碟，進階記憶體磁碟具有更高的效能功能。 如果您要使用標準記憶體將應用程式從 Azure IaaS VM 移轉至進階記憶體，則可能需要較少的進階磁碟來達到應用程式的相同或更高的效能。
磁碟快取
使用進階記憶體的高規模 VM 具有稱為 BlobCache 的多層次快取技術。 BlobCache 會使用主機 RAM 和本機 SSD 的組合來進行快取。 此快取適用於標準 HDD、標準 SSD 和進階 SSD 受控磁碟。 根據預設，此快取設定會設定為OS磁碟的 ReadWrite ，而數據磁碟則設定為 ReadOnly 。 啟用磁碟快取后，高階 VM 可以達到超過基礎磁碟效能的極高效能層級。
警告
4 TiB 和更大的磁碟不支援磁碟快取。 如果多個磁碟連結至您的 VM，則每個小於 4 TiB 的磁碟都支援快取。
變更 Azure 磁碟的快取設定會將目標磁碟中斷連接再重新連接。 如果它是作業系統磁碟，則會重新啟動 VM。 在您變更磁碟快取設定之前，請先停止可能受到此中斷影響的所有應用程式和服務。 未遵循這些建議可能會導致資料損毀。
若要深入瞭解 BlobCache 的運作方式，請參閱 Azure 進階記憶體 內部部落格文章。
務必在正確的一組磁碟上啟用快取。 磁碟上是否應該啟用磁碟快取，取決於磁碟將處理的工作負載模式。 下表顯示OS和數據磁碟的預設快取設定。
| 磁碟類型 | 預設快取設定 |
|---|---|
| 作業系統磁碟 | 讀寫 |
| 資料磁碟 | 唯讀 |
您應該針對資料磁碟設定下列磁碟快取設定：
| 磁碟快取設定 | 使用此設定的時機建議 |
|---|---|
| 沒有 | 針對唯寫和大量寫入的磁碟，將主機快取設定為無。 |
| 唯讀 | 針對唯讀和讀寫的磁碟，將主機快取設定為唯讀。 |
| 讀寫 | 只有當應用程式在必要時可適當地將快取的資料寫入永續性磁碟時，才將主機快取設定為讀寫。 |
唯讀
藉由在數據磁碟上設定 ReadOnly 快取，您可以達到低讀取延遲，並針對您的應用程式取得非常高的讀取 IOPS 和輸送量，原因有兩個：
- 從快取執行的讀取 (在 VM 記憶體和本機 SSD 上)，速度快於從資料磁碟讀取 (在 Azure Blob 儲存體上)。
- 儲存體不會將快取所服務的讀取計入磁碟 IOPS 和輸送量之內。 基於這個理由，您的應用程式可以達到更高的總 IOPS 和輸送量。
讀寫
根據預設，OS 磁碟已啟用 ReadWrite 快取。 我們最近也已在資料磁碟上增加支援讀寫快取。 如果您使用 ReadWrite 快取，您必須有適當的方法，才能將數據從快取寫入永續性磁碟。 例如，SQL Server 會自行負責將快取的資料寫入持久性儲存磁碟。 如果 VM 當機，將 ReadWrite 快取與未處理保存所需資料的應用程式搭配使用，可能會導致數據遺失。
沒有
目前只有數據磁碟支援 None 。 OS 磁碟上不支援它。 如果您在 OS 磁碟上設定 None ，它會在內部覆寫此設定，並將其設定為 ReadOnly。
例如，您可以遵循下列步驟，將這些指導方針套用至在已啟用進階記憶體的 VM 上執行的 SQL Server：
- 在裝載數據文件的標準 HDD、標準 SSD 或進階 SSD 受控磁碟上設定 ReadOnly 快取。
- 從快取中快速讀取能降低 SQL Server 查詢時間，因為數據頁從快取擷取比直接從數據磁碟擷取更加迅速。
- 由快取來服務讀取，表示資料磁碟會有更多輸送量可用。 SQL Server 可以使用這個額外的輸送量來擷取更多數據頁和其他作業，例如備份/還原、批次載入和索引重建。
- 在裝載記錄檔的進階記憶體磁碟上設定 None 快取。
- 記錄檔主要具有大量寫入作業，因此不會受益於 ReadOnly 快取。
將 Linux VM 上的效能優化
對於所有進階 SSD 或 Ultra 磁碟，若已知沒有可能遺失資料的快取，您可以為磁碟上的檔案系統停用障礙，以改善效能。 如果 Azure 磁碟快取設定為 ReadOnly 或 None，您可以停用屏障。 但是，如果快取設定為 ReadWrite，應保持啟用屏障以確保寫入持久性。 根據預設，屏障通常會啟用，但您可以根據文件系統類型，使用下列其中一種方法來停用障礙：
- reiserFS：使用 barrier=none 掛接選項來停用屏障。 若要明確啟用屏障，請使用 barrier=flush。
- ext3/ext4：使用 barrier=0 掛接選項來停用屏障。 若要明確啟用屏障，請使用 barrier=1。
- XFS：使用 nobarrier 掛接選項來停用屏障。 若要明確啟用屏障，請使用 屏障。 從主要 Linux 核心 4.10 版起，XFS 文件系統的設計一律可確保持久性。 停用屏障沒有任何作用，且 nobarrier 選項已被取代。 不過，某些 Linux 發行版可能已將變更回溯至具有較舊核心版本的發行版。 請向您的發行版供應商查詢您正在使用的發行版與版本的狀態。
磁碟等量分割
當高延展性 VM 連接數個進階儲存體永續性磁碟時，磁碟可以串接在一起，以彙總其 IOPS、頻寬和儲存體容量。
在 Windows 中，您可以使用「儲存空間」將磁碟串接在一起。 您必須為集區中的每個磁碟設定一個欄位。 否則，條帶式磁碟區的整體效能可能會低於預期，因為磁碟之間的流量分佈不平均。
透過使用伺服器管理員 UI，將一個等量磁碟區的總欄數最多設定為 8 個。 當連接八個以上的磁碟時，請使用 PowerShell 來建立磁碟區。 您可以使用 PowerShell，將資料行數目設定為等於磁碟數目。 例如，如果單一等量磁碟區中有 16 個磁碟，請在 16 PowerShell Cmdlet 的 NumberOfColumns 參數中指定 New-VirtualDisk 欄。
在 Linux 上，請使用 MDADM 公用程式將磁碟串接在一起。 如需如何在 Linux 上設定等量磁碟的步驟，請參閱 在 Linux 上設定軟體 RAID。
條紋大小
磁碟串接時一項重要設定是等量大小。 等量大小或區塊大小是指應用程式在等量磁碟區上可定址的最小資料區塊。 您配置的磁區大小取決於應用程式的類型及其請求模式。 如果您選擇錯誤的等量大小，可能會導致 I/O 對齊錯錯，進而導致應用程式的效能降低。
例如，如果您的應用程式所產生的 I/O 要求大於磁碟條紋大小，則儲存系統會在多個磁碟上跨越磁碟條紋單位邊界寫入它。 在需要存取該資料時，必須跨越一個以上的等量單位來搜尋，才能完成要求。 這類行為的累積效果可能會導致效能大幅降低。 另一方面，如果 I/O 請求的大小小於條帶大小，且本質上是隨機的，I/O 請求可能會集中在同一個磁碟上，造成瓶頸，最終導致 I/O 效能降低。
視應用程式執行的工作負載類型而定，選擇適當的條帶大小。 對於隨機小型 I/O 要求，請使用較小的等量大小。 對於大型循序 I/O 要求，請使用較大的等量大小。 瞭解您將在高階儲存空間上執行的應用程式的條帶大小建議。 針對 SQL Server，針對 OLTP 工作負載設定 64 KB 的磁碟分條大小，並為資料倉儲的工作負載設定 256 KB。 如需詳細資訊，請參閱 Azure VM 上 SQL Server 的效能最佳做法。
備註
您可以將最多 32 個高效能儲存磁碟串接在 DS 系列虛擬機上，以及將最多 64 個高效能儲存磁碟串接在 GS 系列虛擬機上。
多線程
Azure 將高級存儲平台設計成大規模並行處理。 基於這個理由，多線程應用程式可達到比單個線程應用程式更高的效能。 多線程應用程式會將其工作分割成多個線程，並藉由利用 VM 和磁碟資源達到最大值來提升其執行效率。
例如，如果您的應用程式使用兩個線程在單一核心 VM 上執行，則 CPU 可以在兩個線程之間切換，以達到效率。 當一個線程在磁碟 I/O 上等候完成時，CPU 可以切換至另一個線程。 如此一來，兩個線程可以完成的工作量會超過單一線程。 如果 VM 有多個核心，則會進一步減少運行時間，因為每個核心都可以平行執行工作。
您可能無法變更現成應用程式實作單一線程或多線程的方式。 例如，SQL Server 能夠處理多 CPU 和多核心。 不過，SQL Server 會根據使用一或多個線程來處理查詢的條件來決定。 它可以使用多線程執行查詢和建置索引。 對於在返回使用者之前，牽涉到聯結大型數據表和排序數據的查詢，SQL Server 可能會使用多個線程。 用戶無法使用單一線程或多個線程來控制 SQL Server 是否執行查詢。
您可以改變組態設定，以影響應用程式的多線程或平行處理。 例如，對於 SQL Server，這是 max degree of parallelism 設定。 這個稱為 MAXDOP 的設定可讓您設定 SQL Server 在平行處理時可以使用的最大處理器數目。 您可以為個別的查詢或索引作業設定 MAXDOP。 當您想要平衡系統資源以提升效能重要的應用程式時，這項功能會很有幫助。
例如，假設使用 SQL Server 的應用程式同時執行大型查詢和索引作業。 假設相較於大型查詢，您希望索引作業更有效能。 在這種情況下，您可以將索引作業的 MAXDOP 值設定為高於查詢的 MAXDOP 值。 這樣一來，SQL Server 擁有的處理器數目，比起用於索引作業的處理器數目，還要多於可專用於大型查詢的處理器數目。 請記住，您不會控制 SQL Server 針對每個作業使用的線程數目。 您可以控制用於多線程的處理器數目上限。
深入瞭解 SQL Server 中的 平行處理原則程度 。 瞭解這類設定如何影響應用程式中的多線程，以及其設定以將效能優化。
佇列深度
佇列深度或佇列長度或佇列大小是系統中擱置的 I/O 要求數目。 佇列深度的值會決定您的應用程式可以排隊的 I/O 作業數目，以及記憶體磁碟會處理哪些作業。 這會影響本文所討論的所有三個應用程式效能指標：IOPS、輸送量和延遲。
佇列深度和多線程密切相關。 佇列深度值表示應用程式可以達到多少多線程。 如果佇列深度很大，應用程式可以同時執行更多作業，換句話說，更多的多線程。 如果佇列深度很小，即使應用程式已多線程，也不會有足夠的要求排入佇列以進行並行執行。
一般而言，現成的應用程式不允許您變更佇列深度，因為如果設定不正確，就會造成比良好傷害更多。 應用程式會設定正確的佇列深度值，以獲得最佳效能。 請務必瞭解此概念，以便針對應用程式的效能問題進行疑難解答。 您也可以在系統上執行基準檢驗工具，以觀察佇列深度的影響。
某些應用程式會提供設定來影響佇列深度。 例如，上一節說明 SQL Server 中的 MAXDOP 設定。 MAXDOP 是影響佇列深度和多線程的方法，雖然它不會直接變更 SQL Server 的佇列深度值。
高佇列深度
高佇列深度可讓較多作業在磁碟上排隊。 磁碟會事先知道佇列中的下一個要求。 因此，磁碟可以事先排程作業，並以最佳順序處理作業。 由於應用程式正在將更多要求傳送至磁碟，因此磁碟可以處理更多平行 I/O。 最後，應用程式可以達到更高的 IOPS。 因為應用程式正在處理更多要求，因此應用程式的總輸送量也會增加。
一般而言，應用程式可以在每個連接磁碟上以 8 到 16 個以上待處理的 I/O 獲得最大吞吐量。 如果佇列深度為其中一個，應用程式就不會將足夠的 I/O 推送至系統，而且會在指定的期間內處理較小的數量。 換句話說，輸送量較少。
例如，在 SQL Server 中，將查詢的 MAXDOP 值設定為 4，告知 SQL Server 可以使用最多四個核心來執行該查詢。 SQL Server 會決定查詢執行的最佳佇列深度值和核心數目。
最佳佇列深度
非常高的佇列深度值也有其缺點。 如果佇列深度值太高，應用程式會嘗試驅動非常高的 IOPS。 除非應用程式具有足夠布建 IOPS 的永續性磁碟，高佇列深度值可能會對應用程式的延遲造成負面影響。 下列公式顯示 IOPS、延遲和佇列深度之間的關聯性。
您不應該將佇列深度設定為任何高值，而是將佇列深度設定為最佳值，這可為應用程式提供足夠的 IOPS，而不會影響延遲。 例如，如果應用程式延遲需要 1 毫秒，達到 5,000 IOPS 所需的佇列深度是 QD = 5,000 x 0.001 = 5。
等量磁碟區的佇列深度
對於條帶式磁碟區，請維持足夠高的佇列深度，以便每個磁碟都有個別的峰值佇列深度。 例如，假設應用程式推送的佇列深度為 2，而等量磁碟區中有四個磁碟。 兩個 I/O 要求會移至兩個磁碟，而其餘兩個磁碟則處於閑置狀態。 因此，將佇列深度設定為讓所有磁碟保持忙碌狀態。 下列公式顯示如何決定等量磁碟區的佇列深度。
節流
進階記憶體會根據您選擇的 VM 大小和磁碟大小，布建指定的 IOPS 和輸送量數目。 每當您的應用程式嘗試將 IOPS 或吞吐量提升至超過 VM 或磁碟的處理限制時，高級儲存將進行節流。 結果是應用程式中效能降低，這表示延遲較高、輸送量較低或 IOPS 較低。
如果高級儲存體沒有進行限流，您的應用程式可能會因為超出其資源的極限而全面失效。 若要避免因節流而發生效能問題，請一律為您的應用程式布建足夠的資源。 考慮我們在先前 VM 大小和磁碟大小小節中所討論的內容。 效能評定是找出裝載應用程式所需的資源的最佳方式。
後續步驟
如果您想要對磁碟進行效能評定，請參閱下列文章：
- 針對 Linux： 在 Azure 磁碟記憶體上對您的應用程式進行效能評定
- 針對 Windows： 對磁碟進行效能評定
深入瞭解可用的磁碟類型：
針對 SQL Server 使用者，請參閱 SQL Server 效能最佳做法的文章：