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

# 使用 Amazon CloudWatch 指標來分析 Aurora PostgreSQL 的資源用量
<a name="AuroraPostgreSQL_AnayzeResourceUsage"></a>

Aurora 每隔 1 分鐘會自動將指標資料傳送至 CloudWatch。您可以使用 CloudWatch 指標來分析 Aurora PostgreSQL 的資源用量。您可以使用指標來評估網路輸送量和網路用量。

## 使用 CloudWatch 評估網路輸送量
<a name="AuroraPostgreSQL_AnayzeResourceUsage.EvaluateNetworkThroughput"></a>

當您的系統用量接近執行個體類型的資源限制時，處理速度可能會變慢。您可以使用 CloudWatch **Logs Insights** (日誌洞察)，來監控儲存體資源用量，並確保有足夠的資源可用。需要時，您可以將資料庫執行個體修改為更大的執行個體類別。

 Aurora 儲存體處理速度可能由於下列原因而變慢：
+ 用戶端與資料庫執行個體之間的網路頻寬不足。
+ 儲存體子系統的網路頻寬不足。
+ 對於您的執行個體類型而言很大的工作負載。

您可以查詢 CloudWatch **Logs Insights** (日誌洞察)，來產生 Aurora 儲存體資源用量的圖形以監控資源。此圖會顯示 CPU 使用率和指標，以協助您決定是否要縱向擴展至較大的執行個體大小。如需 CloudWatch **Logs Insights** (日誌洞察) 查詢語法的相關資訊，請參閱 [CloudWatch Logs Insights 查詢語法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)。

若要使用 CloudWatch，您需要將 Aurora PostgreSQL 日誌檔匯出到 CloudWatch。您也可以修改現有的叢集，以將日誌匯出到 CloudWatch。如需將日誌匯出至 CloudWatch 的相關資訊，請參閱 [開啟將日誌發佈到 Amazon CloudWatch 的選項](AuroraPostgreSQL.CloudWatch.Publishing.md)。

您需要資料庫執行個體的 **Resource ID** (資源 ID)，才能查詢 CloudWatch **Logs Insights** (日誌洞察)。**Resource ID** (資源 ID) 可在主控台的 **Configuration** (組態) 索引標籤中找到：

![\[Aurora 主控台 [組態] 索引標籤中的資源 ID。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/Aur_PG_resource_id.png)


**若要查詢資源儲存體指標的日誌檔：**

1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。

   CloudWatch 概觀首頁隨即顯示。

1. 如有需要，請變更 AWS 區域。在導覽列中，選擇 AWS 區域 AWS 資源所在的 。如需詳細資訊，請參閱 [ Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html)。

1. 在導覽窗格中，選擇 **Logs** (日誌)，然後選擇 **Logs Insights** (日誌洞察)。

   **Logs Insights** (日誌洞察) 頁面即會出現。

1. 從下拉式清單選取要分析的日誌檔。

1. 在欄位中輸入下列查詢，將 `<resource ID>` 取代為資料庫叢集的資源 ID：

   `filter @logStream = <resource ID> | parse @message "\"Aurora Storage Daemon\"*memoryUsedPc\":*,\"cpuUsedPc\":*," as a,memoryUsedPc,cpuUsedPc | display memoryUsedPc,cpuUsedPc #| stats avg(xcpu) as avgCpu by bin(5m) | limit 10000`

1. 按一下 **Run query** (執行查詢)。

   即會顯示儲存體使用率圖形。

   下圖提供 **Logs Insights** (日誌洞察) 頁面和圖形顯示。  
![\[Logs Insights 頁面和圖表顯示。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/AurPG-CW-LogsInsights.png)

## 使用 CloudWatch 指標評估 Aurora PostgreSQL 的資料庫執行個體用量
<a name="AuroraPostgreSQL_AnayzeResourceUsage.EvaluateInstanceUsage"></a>

您可以使用 CloudWatch 指標來監看執行個體輸送量，並探索執行個體類別是否為您的應用程式提供足夠的資源。如需資料庫執行個體類別限制的相關資訊，請前往 [Aurora 資料庫執行個體類別的硬體規格](Concepts.DBInstanceClass.Summary.md)並尋找資料庫執行個體類別的規格，以找出您的網路效能。

如果您的資料庫執行個體用量接近執行個體類別限制，效能可能會開始變慢。CloudWatch 指標可以確認這種情況，因此您可以規劃手動縱向擴展到更大的執行個體類別。

結合下列 CloudWatch 指標值，以了解您是否接近執行個體類別限制：
+ **NetworkThroughput** - 用戶端針對 Aurora MySQL 資料庫叢集中各個執行個體所接收和傳輸的網路輸送量。此輸送量值不包含資料庫叢集中的執行個體與叢集磁碟區之間的網路流量。
+ **StorageNetworkThroughput** - Aurora MySQL 資料庫叢集中各個執行個體接收自和傳送至 Aurora 儲存子系統的網路輸送量。

將 **NetworkThroughput** 新增至 **StorageNetworkThroughput**，以尋找 Aurora MySQL 資料庫叢集中各個執行個體接收自和傳送至 Aurora 儲存子系統的網路輸送量。執行個體的執行個體類別限制應該大於這兩個合併指標之和。

 在傳送和接收時，您可以使用下列指標，來檢閱來自用戶端應用程式之網路流量的其他詳細資訊：
+ **NetworkReceiveThroughput** - 資料庫叢集中的各個執行個體從用戶端接收到的網路輸送量。此輸送量不包含資料庫叢集中的執行個體與叢集磁碟區之間的網路流量。
+ **NetworkTransmitThroughput** - Aurora 資料庫叢集中的各個執行個體傳送至用戶端的網路輸送量。此輸送量不包含資料庫叢集中的執行個體與叢集磁碟區之間的網路流量。
+ **StorageNetworkReceiveThroughput** - 資料庫叢集中的各個執行個體從 Aurora 儲存子系統接收到的網路輸送量。
+ **StorageNetworkTransmitThroughput** - 資料庫叢集中的各個執行個體傳送至 Aurora 儲存子系統的網路輸送量。

將所有這些指標加在一起，以評估您的網路用量與執行個體類別限制的比較情形。執行個體類別限制應該大於這些個合併指標之和。

儲存體的網絡限制和 CPU 使用率是交互的。當網路輸送量增加時，CPU 使用率也會增加。監控 CPU 和網路用量可提供資源如何和為何耗盡的相關資訊。

若要協助將網路用量降至最低，您可以考慮：
+ 使用更大的執行個體類別。
+ 使用 `pg_partman` 分割策略。
+ 批次分割寫入要求，以減少整體交易。
+ 將唯讀工作負載導向至唯讀執行個體。
+ 刪除任何未使用的索引。
+ 檢查是否有膨脹的物體和 VACUUM。若有嚴重膨脹，請使用 PostgreSQL 延伸模組 `pg_repack`。如需 `pg_repack` 的詳細資訊，請參閱[以最少的鎖定重組 PostgreSQL 資料庫中的資料表](https://reorg.github.io/pg_repack/)。