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

Aurora Serverless v2 的效能和擴展

下列程序和範例會顯示如何設定 Aurora Serverless v2 羣集及其相關聯資料庫執行個體的容量範圍。您還可使用下列程序，監控資料庫執行個體的繁忙程度。之後，您可使用調查結果來決定是否需要向上或向下調整容量範圍。

在您使用這些程序之前，請確定您熟悉 Aurora Serverless v2 擴展的運作方式。擴展機制與 Aurora Serverless v1 中不同。如需詳細資訊，請參閱 Aurora Serverless v2 擴展。

選擇 Aurora 叢集的 Aurora Serverless v2 容量範圍

利用 Aurora Serverless v2 資料庫執行個體，您可設定套用至資料庫叢集中所有資料庫執行個體的容量範圍，同時新增第一個 Aurora Serverless v2 資料庫執行個體至資料庫叢集。若需執行此作業的程序，請參閱 設定叢集的 Aurora Serverless v2 容量範圍。

您還可變更現有叢集的容量範圍。下列各節會以更詳細的方式討論如何選擇適當的最小值和最大值，及變更容量範圍時會發生的情況。例如，變更容量範圍可修改某些組態參數的預設值。套用所有參數變更可能需要重新啟動每個 Aurora Serverless v2 資料庫執行個體。

選擇叢集的最小值 Aurora Serverless v2 容量設定

總是為最小 Aurora Serverless v2 容量設定選擇 0.5 是很誘人的。該值允許資料庫執行個體在完全閒置時縮減到最小容量，同時保持作用中狀態。您也可以透過指定最小容量為 0 ACUs 來啟用自動暫停行為，如 中所述使用 ACUs自動暫停和繼續將 擴展至零 Aurora Serverless v2。不過，根據您使用該叢集的方式以及您設定的其他設定，不同的最小容量可能最有效。在選擇最小容量設定時，請考慮下列因素：

選擇叢集的最大值 Aurora Serverless v2 容量設定

總是為最大 Aurora Serverless v2 容量設定選擇一些高值是很誘人的。較大的最大容量允許資料庫執行個體在執行密集型工作負載時可以最大程度擴展。較低的值可避免未預期的收費可能性。依據您使用該叢集的方式及您設定的其他設定，最有效的值可能高於或低於您最初想象的值。在選擇最大容量設定時，請考慮下列因素：

範例：變更 Aurora MySQL 叢集的 Aurora Serverless v2 容量範圍

下列 AWS CLI 範例示範如何更新現有 Aurora MySQL Aurora Serverless v2 叢集中資料庫執行個體的 ACU 範圍。一開始叢集的容量範圍為 8–32 個 ACU。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

資料庫執行個體處於閒置狀態，並縮小至 8 個 ACU。此時，下列與容量相關的設定適用於資料庫執行個體。為了以易於讀取的單位表示緩衝區集區的大小，我們將其除以 2 的 30 次方，產生以 gibibyte (GiB) 為單位的測量值。這是因為 Aurora 的記憶體相關測量使用以 2次方為基礎，而不是 10 次方。

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                9294577664 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|   8.65625 |
+-----------+
1 row in set (0.00 sec)

接下來，我們會變更叢集的容量範圍。在 modify-db-cluster 命令完成後，叢集的 ACU 範圍為 12.5–80。

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

變更容量範圍會造成某些組態參數的預設值產生變更。Aurora 可立即套用其中一些新的預設值。但是，某些參數變更僅於重新啟動後生效。pending-reboot 狀態表示需要重新啟動才能套用某些參數的變更。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

此時，叢集處於閒置狀態，而資料庫執行個體 serverless-v2-instance-1 正在消耗 12.5 個 ACU。innodb_buffer_pool_size 參數已根據資料庫執行個體的目前容量進行調整。max_connections 參數仍然反映來自先前最大容量的值。重新設定該值需要重新啟動資料庫執行個體。

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               15572402176 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes     |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)

我們現在會重新啟動資料庫執行個體，並等待其再次可用。

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

pending-reboot 狀態已清除。該值 in-sync 確認 Aurora 已套用所有待定參數變更。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

innodb_buffer_pool_size 參數已增加至其閒置資料庫執行個體的最終大小。已增加 max_connections 參數，來反映從最大 ACU 值衍生出的值。當記憶體大小加倍時，Aurora 用於 max_connections 的公式會增加 1,000。

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               16139681792 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|  15.03125 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              4000 |
+-------------------+
1 row in set (0.00 sec)

我們將容量範圍設定為 0.5–128 ACUs，然後重新啟動資料庫執行個體。閒置資料庫執行個體的緩衝區快取大小現在小於 1 GiB，因此我們以 Mebi 位元組 (MiB) 為單位進行測量。max_connections 值為 5000 衍生自最大容量設定的記憶體大小。

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
|       672 |              5000 |
+-----------+-------------------+
1 row in set (0.00 sec)

範例：變更 Aurora PostgreSQL 叢集的 Aurora Serverless v2 容量範圍

下列 CLI 範例顯示如何更新現有 Aurora PostgreSQL 叢集中 Aurora Serverless v2 資料庫執行個體的 ACU 範圍。

下圖顯示 Amazon CloudWatch 中的容量變更。

資料庫執行個體處於閒置狀態，並縮小至 0.5 個 ACU。此時，下列與容量相關的設定適用於資料庫執行個體。

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

接下來，我們會變更叢集的容量範圍。在 modify-db-cluster 命令完成後，叢集的 ACU 範圍為 8.0–32。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

變更容量範圍會造成某些組態參數的預設值產生變更。Aurora 可立即套用其中一些新的預設值。但是，某些參數變更僅於重新啟動後生效。pending-reboot 狀態表示需要重新啟動才能套用某些參數的變更。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

此時，叢集處於閒置狀態，而資料庫執行個體 serverless-v2-instance-1 正在消耗 8.0 個 ACU。shared_buffers 參數已根據資料庫執行個體的目前容量進行調整。max_connections 參數仍然反映來自先前最大容量的值。重新設定該值需要重新啟動資料庫執行個體。

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

我們會重新啟動資料庫執行個體，並等待其再次可用。

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

資料庫執行個體現已重新啟動，pending-reboot 處於清除狀態。該值 in-sync 確認 Aurora 已套用所有待定參數變更。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

重新啟動後，max_connections 會顯示來自新最大容量的值。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

接下來，我們會將叢集的容量範圍變更為 12.5–80 個 ACU。

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

此時，叢集處於閒置狀態，而資料庫執行個體 serverless-v2-instance-1 正在消耗 12.5 個 ACU。shared_buffers 參數已根據資料庫執行個體的目前容量進行調整。max_connections 值仍然是 5000。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

我們會再次重新啟動，但參數值保持不變。這是因為 max_connections 對於執行 Aurora PostgreSQL 的 Aurora Serverless v2 資料庫叢集具有最大值 5000。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

現在，我們會將容量範圍從 0.5 設為 128 個 ACU。資料庫叢集會縮減規模至 10 個 ACU，然後再縮減規模至 2 個。我們會重新啟動資料庫執行個體。

postgres=> show max_connections;
 max_connections
-----------------
 2000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Aurora Serverless v2 資料庫執行個體的 max_connections 值取決於從最大 ACU 衍生的記憶體大小。不過，當您在 PostgreSQL 相容資料庫執行個體上指定 0 或 0.5 ACUs 的最小容量時， 的最大值max_connections上限為 2，000。

現在，我們將容量恢復到 0.5–1 個 ACU 的初始範圍，然後重新啟動資料庫執行個體。max_connections 參數已返回至原始值。

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

使用 Aurora Serverless v2 的參數群組

建立 Aurora Serverless v2 資料庫叢集時，您可以選擇特定的 Aurora 資料庫引擎和相關的資料庫叢集參數群組。若您不熟悉 Aurora 如何使用參數群組，於叢集間一致地套用組態設定，請參閱 Amazon Aurora 的參數群組。所有為參數群組建立、修改、套用及其他動作的程序皆套用至 Aurora Serverless v2。

參數群組功能在佈建叢集和包含Aurora Serverless v2 資料庫執行個體之叢集間的運作方式通常相同：

預設參數值

佈建資料庫執行個體和 Aurora Serverless v2 資料庫執行個體之間的關鍵差別在於，Aurora 會覆寫與資料庫執行個體容量相關之某些參數的任何自訂參數值。自訂參數值仍可套用至叢集中的任何佈建資料庫執行個體。如需有關 Aurora Serverless v2 資料庫執行個體如何解譯 Aurora 參數群組中參數的更多詳細資訊，請參閱 Aurora 叢集的組態參數。有關 Aurora Serverless v2 覆寫的特定參數，請參閱 Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數 和 Aurora 依據 Aurora Serverless v2 最大容量運算的參數。

使用 describe-db-cluster-parameters CLI 命令並查詢 AWS 區域，您可取得各種 Aurora 資料庫引擎預設參數群組的預設值清單。下列為您可用於與 Aurora Serverless v2 相容之引擎版本的 --db-parameter-group-family 和 -db-parameter-group-name 選項值。

下列範例會從 Aurora MySQL 第 3 版和 Aurora PostgreSQL 13 的預設資料庫叢集群組取得參數清單。這些是您與 Aurora Serverless v2 一起使用的 Aurora MySQL 和 Aurora PostgreSQL 版本。

對於 Linux、 macOS或 Unix：

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-mysql8.0 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-postgresql13 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

在 Windows 中：

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-mysql8.0 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-postgresql13 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

Aurora Serverless v2 的連線數上限

若為 Aurora MySQL 和 Aurora PostgreSQL，Aurora Serverless v2 資料庫執行個體會保持 max_connections 參數不變，則在資料庫執行個體縮減規模時，不會中斷連線。此參數的預設值衍生自以資料庫執行個體記憶體大小為基礎的公式。如需有關佈建資料庫執行個體類別之公式和預設值的詳細資訊，請參閱 Aurora MySQL 資料庫執行個體的最大連線數 和 對 Aurora PostgreSQL 資料庫執行個體的連線數上限。

Aurora Serverless v2 評估公式時，其會使用依據資料庫執行個體的最大 Aurora 容量單位 (ACU) 的記憶體大小，而非目前的 ACU 值。若變更預設值，我們建議使用公式的變化版而非指定常數值。如此，Aurora Serverless v2 可以使用以最大容量為基礎的適當設定。

變更 Aurora Serverless v2 資料庫叢集的最大容量時，您必須重新啟動 Aurora Serverless v2 資料庫執行個體，才能更新 max_connections 值。這是因為 max_connections 是 Aurora Serverless v2 的靜態參數。

下表根據最大 ACU 值顯示 Aurora Serverless v2 的 max_connections 預設值。

如需顯示 max_connections 如何隨著最大 ACU 值而變更的特定範例，請參閱 範例：變更 Aurora MySQL 叢集的 Aurora Serverless v2 容量範圍 和 範例：變更 Aurora PostgreSQL 叢集的 Aurora Serverless v2 容量範圍。

Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數

在自動調整規模期間，Aurora Serverless v2 需要可變更每個資料庫執行個體的參數，以最合適的方法使用增加或減少的容量。因此，您無法覆寫與容量相關的某些參數。若為某些可覆寫的參數，請避免對固定值進行硬編碼。下列注意事項適用於與容量相關的這些設定。

若為 Aurora MySQL，Aurora Serverless v2 在擴展過程中會動態地調整一些參數的大小。若為下列參數，Aurora Serverless v2 不會使用您指定的任何自訂參數值：

若為 Aurora PostgreSQL，Aurora Serverless v2 在擴展期間會動態地調整下列參數參數的大小。若為下列參數，Aurora Serverless v2 不會使用您指定的任何自訂參數值：

若為此處所列出參數以外的所有參數，Aurora Serverless v2 資料庫執行個體的工作方式與佈建的資料庫執行個體相同。預設參數值繼承自叢集參數群組。您可使用自訂叢集參數群組，修改整個叢集的預設值。或者，您可使用自訂資料庫參數群組，修改某些資料庫執行個體的預設值。動態參數會立即更新。僅於您重新啟動資料庫執行個體後，對靜態參數進行的變更才會生效。

Aurora 依據 Aurora Serverless v2 最大容量運算的參數

若為下列參數，Aurora PostgreSQL 會使用預設值，這些預設值衍生自以最大 ACU 設定為基礎的記憶體大小，與 max_connections 相同：

避免記憶體不足錯誤

若您的其中一個 Aurora Serverless v2 資料庫執行個體持續達到其最大容量的限制，Aurora 會將資料庫執行個體的狀態設定為 incompatible-parameters，來指出此狀況。雖然資料庫執行個體的狀態為 incompatible-parameters，但某些作業會遭到封鎖。例如，您無法升級引擎版本。

通常，當資料庫執行個體因記憶體不足錯誤而頻繁重新啟動時，其會進入此狀態。Aurora 會在發生此類型的重新啟動時記錄事件。您可按照 查看 Amazon RDS 活動 中的步驟檢視該事件。因開啟績效詳情和 IAM 身分驗證等設定的額外負荷，可能會發生異常高的記憶體用量。其還可能來自資料庫執行個體上的繁重工作負載或來自管理與大量結構描述物件相關聯的中繼資料。

若記憶體壓力降低，致使資料庫執行個體無法經常達到最大容量，則 Aurora 會自動將資料庫執行個體狀態變更回 available。

如要從此狀況復原，您可進行下列部分或全部動作：

Aurora Serverless v2 的重要 Amazon CloudWatch 指標

如要開始使用您 Aurora Serverless v2 資料庫執行個體的 Amazon CloudWatch，請參閱 在 Amazon CloudWatch 中檢視 Aurora Serverless v2 日誌。若要進一步了解如何透過 CloudWatch 監控 Aurora 資料庫叢集，請參閱 在 Amazon CloudWatch 中監控日誌事件。

您可於 CloudWatch 中檢視 Aurora Serverless v2 資料庫執行個體，使用 ServerlessDatabaseCapacity 指標監控每個資料庫執行個體耗用的容量。您還可監控所有的標準 Aurora CloudWatch 指標，例如 DatabaseConnections 和 Queries 等。如需有關您可監控 Aurora 之 CloudWatch 指標的完整清單，請參閱 Amazon Aurora 的 Amazon CloudWatch 指標。指標分為叢集等級和執行個體等級指標，分別位於 Amazon Aurora 的叢集層級指標 和 Amazon Aurora 的執行個體層級指標 中。

下列 CloudWatch 執行個體等級指標對於監控了解您的 Aurora Serverless v2 資料庫執行個體如何擴展和縮減非常重要。所有這些指標每秒計算一次。如此，您便可監控 Aurora Serverless v2 資料庫執行個體的目前狀態。您可設定警報，以在任何 Aurora Serverless v2 資料庫執行個體接近與容量相關之指標的閾值時通知您。您可決定最小和最大容量設定是否合適，或者是否需要進行調整。您可決定將精力集中於最佳化您資料庫效率之處。

通常，Aurora Serverless v2 資料庫執行個體的大多數擴展是由記憶體用量和 CPU 活動造成的。TempStorageIops 和 TempStorageThroughput 指標可協助您診斷於資料庫執行個體和本機儲存體間進行傳輸之網路活動造成容量意外增加的罕見狀況。如要監控其他網路活動，您可使用以下現有指標：

您可以讓 Aurora 將部分或全部資料庫日誌發佈至 Amazon CloudWatch Logs。如需指示，請參閱下列內容，具體取決於您的資料庫引擎：

Aurora Serverless v2 指標如何套用至您的 AWS 帳單

AWS 帳單上的Aurora Serverless v2費用是根據您可以監控的相同ServerlessDatabaseCapacity指標來計算。若您僅於一個小時的一部分內使用 Aurora Serverless v2 容量，計費機制可能與針對此指標計算的 CloudWatch 平均值不同。若系統問題造成 CloudWatch 指標在短時間內無法使用，其亦可能會有所不同。因此，您可能會看到帳單上的 ACU 小時值與您自己依據 ServerlessDatabaseCapacity 平均值計算的數字略有不同。

Aurora Serverless v2 指標的 CloudWatch 命令範例

下列 AWS CLI 範例示範如何監控與 相關的最重要 CloudWatch 指標Aurora Serverless v2。於每個案例中，將 --dimensions 參數的 Value= 字串替換為您自己的 Aurora Serverless v2 資料庫執行個體識別符。

下列 Linux 範例顯示資料庫執行個體的最小、最大和平均容量值，在一小時內每 10 分鐘測量一次。Linux date 命令指定相對於目前日期和時間的開始和結束時間。--query 參數中的 sort_by 函數依據 Timestamp 欄位依時間順序對結果進行排序。

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

下列 Linux 範例展示了監控叢集中每個資料庫執行個體的容量。其測量每個資料庫執行個體的最小、最大和平均容量使用率。在三個小時內每小時進行一次測量。這些範例使用 ACUUtilization 指標表示 ACU 上限的百分比，而非 ServerlessDatabaseCapacity 表示固定數量的 ACU。如此，您無須知道容量範圍內最小和最大 ACU 值的實際數字。您可看到從 0 到 100 的百分比。

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

下列 Linux 範例執行與先前測量類似的測量。於此狀況下，測量適用於 CPUUtilization 指標。在 1 小時內每 10 分鐘進行一次測量。依據資料庫執行個體的最大容量設定的可用 CPU 資源，這些數字表示已使用的可用 CPU 百分比。

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

下列 Linux 範例執行與先前測量類似的測量。於此狀況下，測量適用於 FreeableMemory 指標。在 1 小時內每 10 分鐘進行一次測量。

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

使用績效詳情監控 Aurora Serverless v2 效能

您可使用績效詳情監控 Aurora Serverless v2 資料庫執行個體的效能。如需有關績效詳情的程序，請參閱 利用 極光上的 Performance Insights 來監控資料庫負載。

下列新的績效詳情計數器適用於 Aurora Serverless v2 資料庫執行個體：

如需績效詳情計數器的完整清單，請參閱 Performance Insights 計數器指標。

在績效詳情中顯示資料庫執行個體的 vCPU 值時，這些值會代表依據 Aurora Serverless v2 資料庫執行個體之 ACU 值的估計值。在預設的一分鐘間隔中，任何小數 vCPU 值皆會無條件進位至最接近的非負整數。若為較長的時間間隔，顯示的 vCPU 值為每分鐘整數 vCPU 值的平均值。

針對 Aurora Serverless v2 容量問題進行疑難排解

在某些情況下，即使資料庫沒有負載，Aurora Serverless v2 也不會縮減規模至最小容量。這種情況可能是由於下列原因而發生：

如果資料庫仍未縮減規模至設定的最小容量，請停止並重新啟動資料庫，以回收任何可能已隨時間建立的記憶體片段。停止和啟動資料庫會導致停機，因此我們建議您謹慎執行此動作。