I/O吞吐限制

• 本地盤實例

  本地SSD盤實例的架構是多個實例共享同一物理機的本地SSD盤，只限制了單個實例的最大IOPS，沒有限制單個實例的I/O吞吐量，因此實際上單個實例的最大I/O吞吐量可以達到1 GB/Sec以上，但同時也存在I/O吞吐資源爭搶問題。如果您需要獨享I/O吞吐資源，建議選擇獨占物理機規格。

• 云盤實例

  云盤實例的架構是單個實例獨立掛載SSD或ESSD云盤，因此I/O資源是完全隔離和獨享的。單個實例的I/O吞吐量上限，取決于實例的計算規格，以及使用的SSD或ESSD云盤的規格和容量。說明如下：

  • RDS SQL Server云盤實例的計算規格主要是ECS 6代規格，I/O吞吐量受相應規格限制。更多信息，請參見通用型實例規格族g6。

  • RDS SQL Server云盤實例的存儲類型有SSD和ESSD兩類，I/O吞吐量受相應存儲類型和容量限制。更多信息，請參見塊存儲性能。

查看I/O吞吐情況

前提條件

實例不能是RDS SQL Server 2008 R2云盤版。

1. 訪問RDS實例列表，在上方選擇地域，然后單擊目標實例ID。

2. 在左側導航欄單擊自治服務 > 性能優化，單擊性能洞察頁簽。

3. 在右側單擊自定義指標，選中IO吞吐量相關性能指標，單擊確定。

   說明

   IO吞吐量的性能指標說明如下：

   • IO_Throughput_Read_Kb：每秒磁盤讀I/O吞吐量。

   • IO_Throughput_Write_kb：每秒磁盤寫I/O吞吐量。

   • IO_Throughput_Total_Kb：每秒磁盤讀I/O吞吐量和寫I/O吞吐量之和。

   

分析與優化I/O吞吐

RDS SQL Server實例的I/O負載主要由數據文件的讀請求和事務日志文件的讀寫請求組成。數據文件的讀請求操作主要包括查詢請求產生的數據頁讀取和數據庫備份產生的數據頁讀取，事務日志文件在做備份時會有較多的讀I/O負載，其他情況主要是寫I/O負載。

當發現實例的I/O吞吐較高時，您可以在自定義指標中增加以下性能指標，然后分析是哪種負載導致的I/O吞吐升高。

分析案例

從I/O吞吐量可以發現，實例的I/O吞吐中讀I/O占比較大，寫I/O占比較小。其中8點到22點這段時間是I/O負載相對平穩的時段，1點到3點和22點到0點，各有一個明顯的I/O吞吐高峰，具體的分析還需要結合其他性能數據。

• 結合Page性能可以發現，1點左右的I/O吞吐量突增主要是讀取數據頁造成的，峰值達到了50000頁左右，即400 MB/sec。

• 結合Page性能、Log性能、備份吞吐量可以發現，2點到3點左右的I/O吞吐高峰由數據頁讀?。ǚ逯导s40 MB/sec）、數據頁寫入（峰值約40 MB/sec）、日志文件寫入（峰值約30 MB/sec）和日志備份（峰值約50 MB/sec）共同組成，累積的I/O吞吐峰值約150 MB/sec。

• 結合Page性能、Log性能可以發現，8點到22點期間的I/O吞吐大部分是數據頁的讀取，約80~100 MB/sec，其次是數據頁的寫入，約30 MB/sec，最后是日志文件的寫入，約5 MB/sec。

• 結合備份吞吐量可以發現，22點到0點的I/O吞吐高峰完全是備份造成的，持續在220 MB/sec以上。

數據頁讀取I/O吞吐高

數據頁讀?。≒age Reads）的I/O吞吐高是導致RDS SQL Server實例I/O吞吐高的原因中最常見的一種，主要原因是實例的緩存不足，導致查詢請求在執行過程中由于緩存無法命中（cache miss），從而需要在磁盤中讀取大量的數據頁。

診斷緩存的一個常用性能指標是頁生命周期（Page Life Expectancy），表示平均每個緩存的數據頁在內存中駐留的時間，單位為秒。時間越短，意味著實例的緩存壓力越大。

通常建議Page Life Expectancy的閾值至少不低于300秒，實例的內存規格越高，建議閾值也越大，公式如下：

建議閾值 = (緩沖池內存大小 / 4 ) x 300

例如16 GB內存規格實例，可用于緩沖池的內存不超過12 GB，建議閾值設置為：(12 / 4) x 300 = 900（秒）

如果是數據頁讀取I/O高導致的實例I/O吞吐負載過高，建議升級實例的內存規格，而不是升級實例的磁盤性能等級。

在數據庫層面也可以通過減少數據頁總量來降低數據頁讀取負載，例如歸檔清理歷史數據、啟用表數據壓縮、刪除低價值索引、整理索引碎片等。

數據頁寫入和日志文件寫入I/O吞吐高

數據頁寫入和日志文件寫入I/O吞吐高，可以通過自治服務觀察寫I/O吞吐高期間是否有頻繁的DML類的寫入操作（INSERT、DELETE、UPDATE、MERGE等）或DDL類的寫入操作（CREATE INDEX、ALTER INDEX等），處理建議如下：

• DML類寫入操作

  首先評估是否為常規業務行為，如果不是，例如為臨時性的數據處理或歸檔操作，請盡量在業務低峰期執行此類操作；如果是，建議升級實例的磁盤性能等級，例如從ESSD PL1到PL2。

  同時建議優化索引結構，刪除不必要的非聚集索引。

• DDL類寫入操作

  通常是數據維護類或臨時性的行為，請盡量在業務低峰期執行此類操作。

  同時建議在創建索引、重建索引等操作時，在SQL語句中使用MAXDOP限制任務執行的并行度，降低執行過程中的磁盤I/O吞吐峰值，但是會延長DDL操作的執行時間。

備份I/O吞吐高

目前RDS SQL Server僅支持在主實例上進行數據備份，會導致主實例的磁盤I/O吞吐增高，其中數據備份（尤其是全量備份）的影響最大，日志備份的影響較小。

由于備份操作是保障RDS數據安全和可靠性必不可少的，因此對于備份導致的I/O吞吐高，建議設置合適的備份時間來降低對業務的影響。

您可以在實例的備份恢復頁面內查看數據備份的耗時，然后避開業務高峰期，選擇合適的備份時間。

• 如果一次全量備份大約需要6小時，每天9點到21點是業務高峰期，22點到1點有后臺數據處理任務，您可以把備份時間設為01:00-02:00，這樣8點之前全量備份就可以完成。備份周期可以設置為每天都備份，需要執行還原操作時，效率也會提高。

• 如果一次全量備份大約需要15小時，工作日任何時間段進行備份都會影響業務，建議將備份周期設置為周六和周日，缺點是如果要通過備份指定時間點還原數據，還原操作的耗時會較長。

如果調整備份時間無法避免全量備份操作和業務的沖突，建議升級實例的磁盤性能等級，或者拆分數據，減少單個實例上的數據量，縮短全量備份所需的時間。