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

的效能和擴展 Aurora Serverless v2

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

使用這些程序之前，請務必熟悉 Aurora Serverless v2 擴展是有效的。擴展機制與 中的不同 Aurora Serverless v1。 如需詳細資訊，請參閱 Aurora Serverless v2 擴展。

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

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

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

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

總是為最小值選擇 0.5 是很誘人的 Aurora Serverless v2 容量設定。該值可允許資料庫執行個體在完全閒置時以最大限度縮減規模。但是，依據您使用該叢集的方式及您設定的其他設定，不同的值可能是最有效的。在選擇最小容量設定時，請考慮下列因素：

選擇上限 Aurora Serverless v2 叢集的容量設定

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

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

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

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

資料庫執行個體處於閒置狀態，並縮減至 8 ACUs。此時，下列與容量相關的設定適用於資料庫執行個體。為了以易於讀取的單位表示緩衝區集區的大小，我們將其除以 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 ACUs。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 Serverless v2 Aurora PostgreSQL 叢集的容量範圍

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

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

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

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 ACUs。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 ACUs。

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 ACUs。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為 5000 Aurora Serverless v2 執行 Aurora Postgre 的資料庫叢集SQL。

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

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

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

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

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

max_connections 的值 Aurora Serverless v2 資料庫執行個體是以衍生自最大 的記憶體大小為基礎ACUs。不過，當您在 Postgre SQL相容的資料庫執行個體ACUs上指定 0.5 的最小容量時， 的最大值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 的參數組 RDS。所有建立、修改、套用和其他參數群組動作的程序都適用於 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-parametersCLI命令並查詢 ，以取得各種 Aurora 資料庫引擎預設參數群組的預設值清單 AWS 區域。以下是可用於 的值，以及相容於 之引擎版本的 --db-parameter-group-family和 -db-parameter-group-name選項 Aurora Serverless v2.

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

用於 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 Postgre SQL，Aurora Serverless v2 資料庫執行個體會保留max_connections參數常數，以便在資料庫執行個體縮減時不會捨棄連線。此參數的預設值衍生自以資料庫執行個體記憶體大小為基礎的公式。如需有關佈建資料庫執行個體類別之公式和預設值的詳細資訊，請參閱 Aurora MySQL 資料庫執行個體的最大連線數 和 至 Aurora SQL 資料庫執行個體的連線上限。

當 Aurora Serverless v2 會根據資料庫執行個體的最大 Aurora 容量單位 （ACUs），而不是目前的ACU值來評估公式，從而使用記憶體大小。若變更預設值，我們建議使用公式的變化版而非指定常數值。這樣，Aurora Serverless v2 可以根據最大容量使用適當的設定。

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

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

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

Aurora 調整為 的參數 Aurora Serverless v2 向上和向下擴展

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

對於 Aurora My SQL，Aurora Serverless v2 在擴展期間動態調整某些參數的大小。針對下列參數：Aurora Serverless v2 不使用您指定的任何自訂參數值：

對於 Aurora Postgre SQL，Aurora Serverless v2 在擴展期間動態調整下列參數的大小。針對下列參數：Aurora Serverless v2 不使用您指定的任何自訂參數值：

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

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

對於下列參數，Aurora PostgreSQL 會根據最大ACU設定使用從記憶體大小衍生的預設值，與 相同max_connections：

避免 out-of-memory錯誤

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

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

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

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

的重要 Amazon CloudWatch 指標 Aurora Serverless v2

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

您可以檢視您的 Aurora Serverless v2 中的資料庫執行個體 CloudWatch ，以使用 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 將部分或全部資料庫日誌發佈至 CloudWatch。您可以在與包含 的叢集相關聯的資料庫叢集參數群組slow_query_log中，開啟組態參數，例如 general_log和 來選取要發佈的日誌 Aurora Serverless v2 資料庫執行個體。當您關閉日誌組態參數時，請將該日誌發佈為 CloudWatch 停止。如果不再需要登入，您也可以刪除 CloudWatch 登入。

方法 Aurora Serverless v2 指標適用於您的 AWS 帳單

所以此 Aurora Serverless v2 AWS 帳單上的費用是根據您可以監控的相同ServerlessDatabaseCapacity指標計算。使用 時，計費機制可能與此指標的計算 CloudWatch 平均值不同 Aurora Serverless v2 容量僅為一小時的一部分。如果系統問題使 CloudWatch 指標短暫無法使用，也可能會有所不同。因此，相較於您自己從ServerlessDatabaseCapacity平均值計算數值，您可能會在帳單上看到 ACU- 小時的略有不同值。

的 CloudWatch 命令範例 Aurora Serverless v2 指標

下列 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指標ACUs，而不是ServerlessDatabaseCapacity代表固定數量的 ACUs。如此一來，您就不需要知道容量範圍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 績效洞察

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

下列新的 Performance Insights 計數器適用於 Aurora Serverless v2 資料庫執行個體：

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

當 vCPU的值顯示為 Aurora Serverless v2 Performance Insights 中的資料庫執行個體，這些值代表基於資料庫執行個體ACU值的估算值。在預設的一分鐘間隔，任何分數 vCPU 值都會四捨五入到最接近的整數。對於較長的間隔，顯示的 vCPU 值是每分鐘整數 vCPU 值的平均值。

故障診斷 Aurora Serverless v2 容量問題

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

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