本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Aurora Serverless v2 的效能和擴展 下列程序和範例會顯示如何設定 Aurora Serverless v2 羣集及其相關聯資料庫執行個體的容量範圍。您還可使用下列程序，監控資料庫執行個體的繁忙程度。之後，您可使用調查結果來決定是否需要向上或向下調整容量範圍。 在您使用這些程序之前，請確定您熟悉 Aurora Serverless v2 擴展的運作方式。擴展機制與 Aurora Serverless v1 中不同。如需詳細資訊，請參閱 [Aurora Serverless v2 擴展](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling)。 **Contents** + [選擇 Aurora 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster) + [選擇叢集的最小值 Aurora Serverless v2 容量設定](#aurora-serverless-v2.min_capacity_considerations) + [選擇叢集的最大值 Aurora Serverless v2 容量設定](#aurora-serverless-v2.max_capacity_considerations) + [範例：變更 Aurora MySQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) + [範例：變更 Aurora PostgreSQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg) + [使用 Aurora Serverless v2 的參數群組](#aurora-serverless-v2.parameter-groups) + [預設參數值](#aurora-serverless-v2.parameter-groups-defaults) + [Aurora Serverless v2 的連線數上限](#aurora-serverless-v2.max-connections) + [Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數](#aurora-serverless-v2.parameters-based-on-scaling) + [Aurora 依據 Aurora Serverless v2 最大容量運算的參數](#aurora-serverless-v2.parameters-based-on-max-capacity) + [避免記憶體不足錯誤](#aurora-serverless-v2.setting-capacity.incompatible_parameters) + [Aurora Serverless v2 的重要 Amazon CloudWatch 指標](#aurora-serverless-v2.viewing.monitoring) + [Aurora Serverless v2 指標如何套用至您的 AWS 帳單](#aurora-serverless-v2-billing) + [Aurora Serverless v2 指標的 CloudWatch 命令範例](#aurora-serverless-v2-cw-examples) + [使用績效詳情監控 Aurora Serverless v2 效能](#aurora-serverless-v2.viewing.performance-insights) + [針對 Aurora Serverless v2 容量問題進行疑難排解](#aurora-serverless-v2.troubleshooting) ## 選擇 Aurora 叢集的 Aurora Serverless v2 容量範圍 利用 Aurora Serverless v2 資料庫執行個體，您可設定套用至資料庫叢集中所有資料庫執行個體的容量範圍，同時新增第一個 Aurora Serverless v2 資料庫執行個體至資料庫叢集。若需執行此作業的程序，請參閱 [設定叢集的 Aurora Serverless v2 容量範圍](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus)。 您還可變更現有叢集的容量範圍。下列各節會以更詳細的方式討論如何選擇適當的最小值和最大值，及變更容量範圍時會發生的情況。例如，變更容量範圍可修改某些組態參數的預設值。套用所有參數變更可能需要重新啟動每個 Aurora Serverless v2 資料庫執行個體。 **Topics** + [選擇叢集的最小值 Aurora Serverless v2 容量設定](#aurora-serverless-v2.min_capacity_considerations) + [選擇叢集的最大值 Aurora Serverless v2 容量設定](#aurora-serverless-v2.max_capacity_considerations) + [範例：變更 Aurora MySQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) + [範例：變更 Aurora PostgreSQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg) ### 選擇叢集的最小值 Aurora Serverless v2 容量設定 總是為最小 Aurora Serverless v2 容量設定選擇 0.5 是很誘人的。該值可讓資料庫執行個體在完全閒置時縮減規模至最小容量，同時保持作用中狀態。您也可以指定最小容量為 0 個 ACU 來啟用自動暫停行為，如 [使用 Aurora Serverless v2 的自動暫停和繼續擴展至零個 ACU](aurora-serverless-v2-auto-pause.md) 中所述。但是，依據您使用該叢集的方式及您設定的其他設定，不同的最小容量可能是最有效的。在選擇最小容量設定時，請考慮下列因素： + Aurora Serverless v2 資料庫執行個體的擴展率依其目前容量而定。目前的容量越高，則擴充規模就越快。若您需要資料庫執行個體快速擴展至非常高的容量，請考慮將最小容量設定為擴展率符合您要求的值。 + 若您通常在預期工作負載特別高或低的情況下修改資料庫執行個體的資料庫執行個體類別，則可使用該體驗粗略估計等效的 Aurora Serverless v2 容量範圍。如要決定低流量時要使用的記憶體大小，請參閱 [Aurora 資料庫執行個體類別的硬體規格](Concepts.DBInstanceClass.Summary.md)。 例如，假設您在叢集的工作負載較低時，使用 db.r6g.xlarge 資料庫執行個體類別。該資料庫執行個體類別有 32 GiB 的記憶體。因此，您可將 Aurora 容量單位 (ACU) 的最小設定指定為 16，來設定 Aurora Serverless v2 資料庫執行個體，此可縮小至大約相同的容量。這是因為每個 ACU 對應至大約 2 GiB 的記憶體。如果您的 db.r6g.xlarge 資料庫執行個體有時並未充分利用，則您可指定一個較低的值，以進一步縮小資料庫執行個體。 + 若資料庫執行個體在緩衝區快取中具有一定數量的資料時，您的應用程式運作效率最高，請考慮指定最小 ACU 設定，其記憶體夠大足以容納頻繁存取的資料。否則，當 Aurora Serverless v2 資料庫執行個體縮減至較低的記憶體大小時。則會從緩衝區快取中移出一些資料。然後，當資料庫執行個體擴展進行備份時，資訊將隨著時間的推移讀回緩衝區快取中。若要將資料帶回緩衝區快取的 I/O 量很大，則選擇較高的最小 ACU 值可能會更有效。 + 若您的 Aurora Serverless v2 資料庫執行個體大部分時間都以特定容量執行，請考慮指定低於該基準但不要太低的最小容量設定。Aurora Serverless v2當目前容量並未明顯低於所需容量時，資料庫執行個體可最有效地估計擴充規模的數量和速度。 + 若您佈建的工作負載對於 T3 或 T4g 等小型資料庫執行個體類別的記憶體要求過高，請選擇提供與 R5 或 R6g 資料庫執行個體相當的記憶體最小 ACU 設定。 我們特別建議與指定功能一起使用的下列最小容量 (這些建議可能會發生變化)： + Performance Insights – 2 個 ACU + Aurora 全域資料庫 – 8 個 ACU (僅適用於主要 AWS 區域) + 在 Aurora 中，複寫發生在儲存層，因此讀取器容量不會直接影響複寫。不過，對於獨立擴展的 Aurora Serverless v2 讀取器資料庫執行個體，請確定最小容量足以在寫入密集期間處理工作負載，以避免查詢延遲。如果提升 2–15 層中的讀取器資料庫執行個體遇到效能問題，請考慮增加叢集的最小容量。如需有關選擇讀取器資料庫執行個體是隨寫入器擴展還是獨立擴展的詳細資訊，請參閱 [選擇 Aurora Serverless v2 讀取器的提升層](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier)。 + 如果您有具有 Aurora Serverless v2 讀取器資料庫執行個體的資料庫叢集，當讀取器的提升層不是 0 或 1 時，讀取器不會與寫入器資料庫執行個體一起擴展。在這種情況下，設定較低的最小容量可能會導致過多的複寫延遲。這是因為讀取器可能沒有足夠的容量，無法在資料庫繁忙時套用寫入器的變更。我們建議您將最小容量設定為代表與寫入器資料庫執行個體相當之記憶體和 CPU 數量的值。 + Aurora Serverless v2 資料庫執行個體的 `max_connections` 參數值取決於從最大 ACU 衍生的記憶體大小。但是，當您指定 PostgreSQL 相容資料庫執行個體的最小容量為 0 或 0.5 個 ACU 時，`max_connections` 的上限值會設定為 2,000。 若要將 Aurora PostgreSQL 叢集用於高連線工作負載，請考慮使用最小 1 或更高的 ACU 設定。如需有關 Aurora Serverless v2 處理 `max_connections` 組態參數的方法，請參閱 [Aurora Serverless v2 的連線數上限](#aurora-serverless-v2.max-connections)。 + Aurora Serverless v2 資料庫執行個體從最小容量擴展至最大容量所需的時間取決於其最小和最大 ACU 值之間的差異。當資料庫執行個體的目前容量較大時，Aurora Serverless v2 擴充規模的增量較資料庫執行個體從小容量開始的增量更大。因此，若您指定了相對較大的最大容量，且資料庫執行個體的大部分時間花在該容量附近，請考慮增加最小 ACU 設定。這樣，閒置資料庫執行個體便可更快速地擴展至最大容量。 ### 選擇叢集的最大值 Aurora Serverless v2 容量設定 總是為最大 Aurora Serverless v2 容量設定選擇一些高值是很誘人的。較大的最大容量允許資料庫執行個體在執行密集型工作負載時可以最大程度擴展。較低的值可避免未預期的收費可能性。依據您使用該叢集的方式及您設定的其他設定，最有效的值可能高於或低於您最初想象的值。在選擇最大容量設定時，請考慮下列因素： + 最大容量必須至少與最小容量相同。您可將最小和最大容量設定為相同。但是，在這種情況下，容量永遠不會擴展或縮小。因此，除了在測試情況下，對最小和最大容量使用相同的值並不合適。 + 最大容量必須高於 0.5 ACU。在大多數情況下，您可將最小和最大容量設定為相同。但是，不可為最小值和最大值指定 0.5。使用 1 或更高的值作為最大容量。 + 若您通常在預期工作負載特別高或低的情況下修改資料庫執行個體的資料庫執行個體類別，則可使用該體驗來估計等效的 Aurora Serverless v2 容量範圍。如要決定高流量時要使用的記憶體大小，請參閱 [Aurora 資料庫執行個體類別的硬體規格](Concepts.DBInstanceClass.Summary.md)。 例如，假設您在叢集的工作負載較高時，使用 db.r6g.4xlarge 資料庫執行個體類別。該資料庫執行個體類別有 128 GiB 的記憶體。因此，您可將最大 ACU 設定指定為 64，來設定 Aurora Serverless v2 資料庫執行個體，此可擴展至大約相同的容量。這是因為每個 ACU 對應至大約 2 GiB 的記憶體。若 db.r6g.4xlarge 資料庫執行個體有時並無足夠的容量來有效處理工作負載，您可指定一個稍高的值，讓資料庫執行個體進一步向上擴展。 + 若您的資料庫用量有預算上限，請選擇一個保持在該上限內的值，即使您的 Aurora Serverless v2 資料庫執行個體一直都以最大容量執行。請記住，當您的叢集中有 *n* 個 Aurora Serverless v2資料庫執行個體時，依理論，叢集在任何時候可消耗的最大 Aurora Serverless v2 容量為叢集最大 ACU 設定的 *n* 倍。(實際消耗量可能會減少，例如，若某些讀取器獨立於寫入器擴展。) + 若您使用 Aurora Serverless v2 讀取器資料庫執行個體從寫入器資料庫執行個體中卸載部分唯讀工作負載，則可選擇較低的最大容量設定。您這麼做是為了反映每個讀取器資料庫執行個體毋需像叢集僅包含單一資料庫執行個體那麼高的擴展。 + 假設您想要防止因資料庫參數設定錯誤或應用程式中的效率低查詢而造成的過度使用。於這種情況下，您可透過選擇低於您可設定的絕對最高容量設定來避免意外過度使用。 + 若因實際使用者活動所引起的峯值很少，但確實發生，您可在選擇最大容量設定時考慮這些情況。若優先順序是讓應用程式以完整的效能和可擴展性持續執行，您可指定一個高於正常用量下所觀察到的最大容量設定。若應用程式可在活動極端高峯期間以縮減的輸送量執行，則可選擇稍低的最大容量設定。確保您選擇的設定仍具有足夠的記憶體和 CPU 資源，以保持應用程式的執行。 + 若您在叢集中啟用了增加每個資料庫執行個體的記憶體用量的設定，請在決定最大 ACU 值時考慮該記憶體。這些設定包括績效詳情、Aurora MySQL 平行查詢、Aurora MySQL 效能結構描述和 Aurora MySQL 二進位日誌複寫的設定。請確保最大 ACU 值允許 Aurora Serverless v2 資料庫執行個體的擴充規模足以在使用這些功能時處理工作負載。如需有關對由低位最大 ACU 設定和利用記憶體額外負荷之 Aurora 功能組合所造成問題進行疑難排解的資訊，請參閱 [避免記憶體不足錯誤](#aurora-serverless-v2.setting-capacity.incompatible_parameters)。 ### 範例：變更 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` 參數仍然反映來自先前最大容量的值。重新設定該值需要重新啟動資料庫執行個體。 **注意** 如果您直接在自訂資料庫參數群組中設定 `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 個 ACU，然後重新啟動資料庫執行個體。閒置資料庫執行個體的緩衝區快取大小現在小於 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 範圍。 1. 叢集的容量範圍從 0.5–1 個 ACU 開始。 1. 將容量範圍變更為 8–32 個 ACUS。 1. 將容量範圍變更為 12.5–80 個 ACUS。 1. 將容量範圍變更為 0.5–128 個 ACUS。 1. 將容量恢復到 0.5–1 個 ACU 的初始範圍。 下圖顯示 Amazon CloudWatch 中的容量變更。 ![\[Aurora Serverless v2 容量變更的 CloudWatch 圖\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/sv2-apg-scaling-example.png) 資料庫執行個體處於閒置狀態，並縮小至 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` 參數仍然反映來自先前最大容量的值。重新設定該值需要重新啟動資料庫執行個體。 **注意** 如果您直接在自訂資料庫參數群組中設定 `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 個 ACU 時，`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 的參數群組](USER_WorkingWithParamGroups.md)。所有為參數群組建立、修改、套用及其他動作的程序皆套用至 Aurora Serverless v2。 參數群組功能在佈建叢集和包含Aurora Serverless v2 資料庫執行個體之叢集間的運作方式通常相同： + 叢集中所有資料庫執行個體的預設參數值由叢集參數群組進行定義。 + 您可為這些資料庫執行個體指定自訂資料庫參數群組，來覆寫特定資料庫執行個體的某些參數。您可於特定資料庫執行個體的偵錯或效能調校過程中執行此作業。例如，假設您有一個包含一些 Aurora Serverless v2 資料庫執行個體和一些佈建資料庫執行個體的叢集。於此狀況下，您可使用自訂資料庫參數群組為佈建的資料庫執行個體指定一些不同的參數。 + 若為 Aurora Serverless v2，您可使用參數群組之 `SupportedEngineModes` 屬性中值為 `provisioned` 的所有參數。於 Aurora Serverless v1 中，您僅可使用 `SupportedEngineModes` 屬性中具有 `serverless` 的參數子集。 **Topics** + [預設參數值](#aurora-serverless-v2.parameter-groups-defaults) + [Aurora Serverless v2 的連線數上限](#aurora-serverless-v2.max-connections) + [Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數](#aurora-serverless-v2.parameters-based-on-scaling) + [Aurora 依據 Aurora Serverless v2 最大容量運算的參數](#aurora-serverless-v2.parameters-based-on-max-capacity) ### 預設參數值 佈建資料庫執行個體和 Aurora Serverless v2 資料庫執行個體之間的關鍵差別在於，Aurora 會覆寫與資料庫執行個體容量相關之某些參數的任何自訂參數值。自訂參數值仍可套用至叢集中的任何佈建資料庫執行個體。如需有關 Aurora Serverless v2 資料庫執行個體如何解譯 Aurora 參數群組中參數的更多詳細資訊，請參閱 [Aurora 叢集的組態參數](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.parameters)。有關 Aurora Serverless v2 覆寫的特定參數，請參閱 [Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數](#aurora-serverless-v2.parameters-based-on-scaling) 和 [Aurora 依據 Aurora Serverless v2 最大容量運算的參數](#aurora-serverless-v2.parameters-based-on-max-capacity)。 使用 [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) CLI 命令並查詢 AWS 區域，您可取得各種 Aurora 資料庫引擎預設參數群組的預設值清單。下列為您可用於與 Aurora Serverless v2 相容之引擎版本的 `--db-parameter-group-family` 和 `-db-parameter-group-name` 選項值。 | 資料庫引擎和版本 | 參數群組系列 | 預設參數群組名稱 | | --- | --- | --- | | Aurora MySQL 第 3 版 | `aurora-mysql8.0` | `default.aurora-mysql8.0` | | Aurora PostgreSQL 13.x 版 | `aurora-postgresql13` | `default.aurora-postgresql13` | | Aurora PostgreSQL 14.x 版 | `aurora-postgresql14` | `default.aurora-postgresql14` | | Aurora PostgreSQL 15.x 版 | `aurora-postgresql15` | `default.aurora-postgresql15` | | Aurora PostgreSQL 16.x 版 | `aurora-postgresql16` | `default.aurora-postgresql16` | | Aurora PostgreSQL 17.x 版 | `aurora-postgresql17` | `default.aurora-postgresql17` | 下列範例會從 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 資料庫執行個體的連線數上限](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) 和 [對 Aurora PostgreSQL 資料庫執行個體的連線數上限](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections)。 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` 預設值。 | 最大 ACU | Aurora MySQL 上的預設連線數上限 | Aurora PostgreSQL 上的預設連線數上限 | | --- | --- | --- | | 1 | 90 | 189 | | 4 | 135 | 823 | | 8 | 1,000 | 1，669 | | 16 | 2,000 | 3，360 | | 32 | 3,000 | 5,000 | | 64 | 4,000 | 5,000 | | 128 | 5,000 | 5,000 | | 192 | 6,000 | 5,000 | | 256 | 6,000 | 5,000 | **注意** Aurora Serverless v2 資料庫執行個體的 `max_connections` 值取決於從最大 ACU 衍生的記憶體大小。但是，當您指定 PostgreSQL 相容資料庫執行個體的最小容量為 0 或 0.5 個 ACU 時，`max_connections` 的上限值會設定為 2,000。 如需顯示 `max_connections` 如何隨著最大 ACU 值而變更的特定範例，請參閱 [範例：變更 Aurora MySQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) 和 [範例：變更 Aurora PostgreSQL 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg)。 ### Aurora 在 Aurora Serverless v2 放大和縮小時調整的參數 在自動調整規模期間，Aurora Serverless v2 需要可變更每個資料庫執行個體的參數，以最合適的方法使用增加或減少的容量。因此，您無法覆寫與容量相關的某些參數。若為某些可覆寫的參數，請避免對固定值進行硬編碼。下列注意事項適用於與容量相關的這些設定。 若為 Aurora MySQL，Aurora Serverless v2 在擴展過程中會動態地調整一些參數的大小。若為下列參數，Aurora Serverless v2 不會使用您指定的任何自訂參數值： + `innodb_buffer_pool_size` + `innodb_purge_threads` + `table_definition_cache` + `table_open_cache` 若為 Aurora PostgreSQL，Aurora Serverless v2 在擴展期間會動態地調整下列參數參數的大小。若為下列參數，Aurora Serverless v2 不會使用您指定的任何自訂參數值： + `shared_buffers` 若為此處所列出參數以外的所有參數，Aurora Serverless v2 資料庫執行個體的工作方式與佈建的資料庫執行個體相同。預設參數值繼承自叢集參數群組。您可使用自訂叢集參數群組，修改整個叢集的預設值。或者，您可使用自訂資料庫參數群組，修改某些資料庫執行個體的預設值。動態參數會立即更新。僅於您重新啟動資料庫執行個體後，對靜態參數進行的變更才會生效。 ### Aurora 依據 Aurora Serverless v2 最大容量運算的參數 若為下列參數，Aurora PostgreSQL 會使用預設值，這些預設值衍生自以最大 ACU 設定為基礎的記憶體大小，與 `max_connections` 相同： + `autovacuum_max_workers` + `autovacuum_vacuum_cost_limit` + `autovacuum_work_mem` + `effective_cache_size` + `maintenance_work_mem` ## 避免記憶體不足錯誤 若您的其中一個 Aurora Serverless v2 資料庫執行個體持續達到其最大容量的限制，Aurora 會將資料庫執行個體的狀態設定為 `incompatible-parameters`，來指出此狀況。雖然資料庫執行個體的狀態為 `incompatible-parameters`，但某些作業會遭到封鎖。例如，您無法升級引擎版本。 通常，當資料庫執行個體因記憶體不足錯誤而頻繁重新啟動時，其會進入此狀態。Aurora 會在發生此類型的重新啟動時記錄事件。您可按照 [檢視 Amazon RDS 事件](USER_ListEvents.md) 中的步驟檢視該事件。因開啟績效詳情和 IAM 身分驗證等設定的額外負荷，可能會發生異常高的記憶體用量。其還可能來自資料庫執行個體上的繁重工作負載或來自管理與大量結構描述物件相關聯的中繼資料。 若記憶體壓力降低，致使資料庫執行個體無法經常達到最大容量，則 Aurora 會自動將資料庫執行個體狀態變更回 `available`。 如要從此狀況復原，您可進行下列部分或全部動作： + 變更叢集的最小 Aurora 容量單位 (ACU) 值，增加 Aurora Serverless v2 資料庫執行個體的容量下限。如此可避免閒置資料庫縮減規模至記憶體容量少於叢集中啟用功能所需的容量問題。變更叢集的 ACU 設定後，重新啟動 Aurora Serverless v2 資料庫執行個體。如此可評估 Aurora 是否將狀態重設為 `available`。 + 變更叢集的最大 Aurora 容量單位 (ACU) 值，增加 Aurora Serverless v2 資料庫執行個體的容量上限。如此可避免繁忙的資料庫無法擴充規模至具足夠記憶體的容量，以滿足叢集和資料庫工作負載中所開啟功能的問題。變更叢集的 ACU 設定後，重新啟動 Aurora Serverless v2 資料庫執行個體。如此可評估 Aurora 是否將狀態重設為 `available`。 + 請關閉需要記憶體額外負荷的組態設定。例如，假設您已開啟 AWS Identity and Access Management (IAM)、績效詳情或 Aurora MySQL 二進位日誌複寫等功能，但不使用它們。若是如此，您可將其關閉。或者，您可將叢集的最小和最大容量值調整得更高，以考慮這些功能所使用的記憶體。如需有關選擇最小和最大容量設定的指導方針，請參閱 [選擇 Aurora 叢集的 Aurora Serverless v2 容量範圍](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)。 + 縮減資料庫執行個體的工作負載。例如，您可將讀取器資料庫執行個體新增至叢集，以將來自唯讀查詢的負載分散至更多的資料庫執行個體中。 + 調整應用程式所使用的 SQL 程式碼，以使用較少的資源。例如，您可檢查您的查詢計畫、檢查慢查詢日誌或調整資料表上的索引。您還可執行其他傳統類型的 SQL 調校。 ## Aurora Serverless v2 的重要 Amazon CloudWatch 指標 如要開始使用您 Aurora Serverless v2 資料庫執行個體的 Amazon CloudWatch，請參閱 [在 Amazon CloudWatch 中檢視 Aurora Serverless v2 日誌](aurora-serverless-v2-administration.md#aurora-serverless-v2.logging.monitoring)。若要進一步了解如何透過 CloudWatch 監控 Aurora 資料庫叢集，請參閱 [在 Amazon CloudWatch 中監控日誌事件](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor)。 您可於 CloudWatch 中檢視 Aurora Serverless v2 資料庫執行個體，使用 `ServerlessDatabaseCapacity` 指標監控每個資料庫執行個體耗用的容量。您還可監控所有的標準 Aurora CloudWatch 指標，例如 `DatabaseConnections` 和 `Queries` 等。如需有關您可監控 Aurora 之 CloudWatch 指標的完整清單，請參閱 [Amazon Aurora 的 Amazon CloudWatch 指標](Aurora.AuroraMonitoring.Metrics.md)。指標分為叢集等級和執行個體等級指標，分別位於 [Amazon Aurora 的叢集層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters) 和 [Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances) 中。 下列 CloudWatch 執行個體等級指標對於監控了解您的 Aurora Serverless v2 資料庫執行個體如何擴展和縮減非常重要。所有這些指標每秒計算一次。如此，您便可監控 Aurora Serverless v2 資料庫執行個體的目前狀態。您可設定警報，以在任何 Aurora Serverless v2 資料庫執行個體接近與容量相關之指標的閾值時通知您。您可決定最小和最大容量設定是否合適，或者是否需要進行調整。您可決定將精力集中於最佳化您資料庫效率之處。 + `ServerlessDatabaseCapacity`。作為執行個體等級指標，其報告目前資料庫執行個體容量所代表的 ACU 數量。作為叢集等級指標，其代表叢集中所有 Aurora Serverless v2 資料庫執行個體的 `ServerlessDatabaseCapacity` 值的平均值。該指標只是 Aurora Serverless v1 中的叢集等級指標。於 Aurora Serverless v2 中，其可用於資料庫執行個體等級和叢集等級。 + `ACUUtilization`。該指標是 Aurora Serverless v2 中的新指標。此值以百分比表示。其計算方法為 `ServerlessDatabaseCapacity` 指標的值除以資料庫叢集的最大 ACU 值。請考慮下列指導方針來解譯此指標並採取行動： + 若此指標接近 `100.0` 值，則資料庫執行個體已盡可能地擴展。考慮增加叢集的最大 ACU 設定。如此，寫入器和讀取器資料庫執行個體皆可擴展至更高的容量。 + 假設唯讀工作負載會導致讀取器資料庫執行個體接近 `100.0` 的 `ACUUtilization`，而寫入器資料庫執行個體並未接近其最大容量。於該狀況下，請考慮將額外的讀取器資料庫執行個體新增至叢集。如此，您可將工作負載的唯讀部分分散至更多資料庫執行個體中，進而減少每個讀取器資料庫執行個體的負載。 + 假設您正在執行生產應用程式，其中效能和可擴展性是主要考慮因素。於該狀況下，您可將叢集的最大 ACU 值設定為較高的數字。您的目標適用於始終低於 `100.0` 的 `ACUUtilization` 指標。使用較高的最大 ACU 值，您可確信有足夠的空間以防資料庫活動出現意外高峰。您僅需為實際使用的資料庫容量付費。 + `CPUUtilization`。此指標在 Aurora Serverless v2 中的解譯與在佈建的資料庫執行個體中不同。若為 Aurora Serverless v2，此值是一個百分比，計算方法為目前使用的 CPU 量除以資料庫叢集最大 ACU 值下可用的 CPU 容量。Aurora 會自動監控此值並在資料庫執行個體持續使用其 CPU 容量的高比例時擴展您的 Aurora Serverless v2 資料庫執行個體。 若此指標接近 `100.0` 值，則資料庫執行個體已達到其最大 CPU 容量。考慮增加叢集的最大 ACU 設定。若此指標在讀取器資料庫執行個體上接近 `100.0` 的值，請考慮將其他讀取器資料庫執行個體新增至叢集。如此，您可將工作負載的唯讀部分分散至更多資料庫執行個體中，進而減少每個讀取器資料庫執行個體的負載。 + `FreeableMemory`。此值表示當 Aurora Serverless v2 資料庫執行個體擴展至其最大容量時可用的未使用記憶體量。若為目前容量低於最大容量的每個 ACU，此值增加約 2 GiB。因此，在資料庫執行個體盡可能向上擴展之前，該指標不會接近零。 若此指標接近 `0` 值，則資料庫執行個體已盡可能地進行擴展，且接近其可用記憶體的限制。考慮增加叢集的最大 ACU 設定。若此指標在讀取器資料庫執行個體上接近 `0` 的值，請考慮將其他讀取器資料庫執行個體新增至叢集。如此，工作負載的唯讀部分可分佈於更多資料庫執行個體上，進而減少每個讀取器資料庫執行個體上的記憶體用量。 + `TempStorageIOPS`。在附加至資料庫執行個體的本機儲存體上完成的 IOPS 數。其包括讀取和寫入的 IOPS。此指標表示計數，且每秒測量一次。這是 Aurora Serverless v2 的一個新指標。如需詳細資訊，請參閱[Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。 + `TempStorageThroughput`。傳入和傳出與資料庫執行個體相關聯之本機儲存體的資料量。此指標表示位元組，且每秒測量一次。這是 Aurora Serverless v2 的一個新指標。如需詳細資訊，請參閱[Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。 通常，Aurora Serverless v2 資料庫執行個體的大多數擴展是由記憶體用量和 CPU 活動造成的。`TempStorageIOPS` 和 `TempStorageThroughput` 指標可協助您診斷於資料庫執行個體和本機儲存體間進行傳輸之網路活動造成容量意外增加的罕見狀況。如要監控其他網路活動，您可使用以下現有指標： + `NetworkReceiveThroughput` + `NetworkThroughput` + `NetworkTransmitThroughput` + `StorageNetworkReceiveThroughput` + `StorageNetworkThroughput` + `StorageNetworkTransmitThroughput` 您可讓 Aurora 發佈部分或所有資料庫日誌到 Amazon CloudWatch Logs。如需指示，請視您的資料庫引擎而定參閱下列內容： + [將 Aurora PostgreSQL 日誌發佈至 Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md) + [將 Amazon Aurora MySQL 日誌發佈至 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md) ### 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 資料庫執行個體的效能。如需有關績效詳情的程序，請參閱 [在 Amazon Aurora 上使用績效詳情監控資料庫負載](USER_PerfInsights.md)。 下列新的績效詳情計數器適用於 Aurora Serverless v2 資料庫執行個體： + `os.general.serverlessDatabaseCapacity` – ACU 中資料庫執行個體的目前容量。該值對應至 `ServerlessDatabaseCapacity` 資料庫執行個體的 CloudWatch 指標。 + `os.general.acuUtilization` – 目前容量佔最大設定容量的百分比。該值對應至 `ACUUtilization` 資料庫執行個體的 CloudWatch 指標。 + `os.general.maxConfiguredAcu` – 您為此 Aurora Serverless v2 資料庫執行個體設定的最大容量。其以 ACU 為單位進行測量。 + `os.general.minConfiguredAcu` – 您為此 Aurora Serverless v2 資料庫執行個體設定的最小容量。其以 ACU 為單位進行測量。 如需績效詳情計數器的完整清單，請參閱 [Performance Insights 計數器指標](USER_PerfInsights_Counters.md)。 在績效詳情中顯示資料庫執行個體的 `vCPU` 值時，這些值會代表依據 Aurora Serverless v2 資料庫執行個體之 ACU 值的估計值。在預設的一分鐘間隔中，任何小數 vCPU 值皆會無條件進位至最接近的非負整數。若為較長的時間間隔，顯示的 vCPU 值為每分鐘整數 vCPU 值的平均值。 ## 針對 Aurora Serverless v2 容量問題進行疑難排解 在某些情況下，即使資料庫沒有負載，Aurora Serverless v2 也不會縮減規模至最小容量。這種情況可能是由於下列原因而發生： + 某些功能可以增加資源使用量，並防止資料庫縮減規模至最小容量。重要功能如下所示： + Aurora 全球資料庫 + 探索 CloudWatch Logs + 在 Aurora PostgreSQL 相容的資料庫叢集上啟用 `pg_audit` + Enhanced Monitoring (增強型監控) + Performance Insights 如需詳細資訊，請參閱[選擇叢集的最小值 Aurora Serverless v2 容量設定](#aurora-serverless-v2.min_capacity_considerations)。 + 如果讀取器執行個體未縮減規模至最小值，且維持與寫入器執行個體相同或比其更高的容量，請檢查讀取器執行個體的優先順序方案。方案 0 或方案 1 的 Aurora Serverless v2 讀取器資料庫執行個體保持至少與寫入器資料庫執行個體一樣高的最小容量。將讀取器的優先順序方案變更為 2 或更高，以便其可以獨立縱向擴展和縮減，與寫入器無關。如需詳細資訊，請參閱[選擇 Aurora Serverless v2 讀取器的提升層](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier)。 + 將影響共用記憶體大小的任何資料庫參數設為其預設值。設定高於預設值的值會增加共用記憶體需求，並防止資料庫縮減規模至最小容量。範例包括 `max_connections` 和 `max_locks_per_transaction`。 **注意** 更新共用記憶體參數需要重新啟動資料庫，變更才能生效。 + 繁重的資料庫工作負載會增加資源使用量。 + 大型資料庫磁碟區會增加資源使用量。 Amazon Aurora 使用記憶體和 CPU 資源進行資料庫叢集管理。管理資料庫磁碟區更大的資料庫叢集，Aurora 需要更多 CPU 和記憶體。如果叢集的容量下限低於叢集管理所需的最小容量，則您的叢集將不會縮減至容量下限。 + 背景程序 (例如清除) 也可能會增加資源使用量。 + 平台版本限制可能會影響擴展功能。特定叢集的可用擴展範圍受引擎版本和硬體 (平台版本) 影響。可以在功能較差的平台版本上執行更強大的引擎版本，反之亦然。 如果資料庫仍未縮減規模至設定的最小容量，請停止並重新啟動資料庫，以回收任何可能已隨時間建立的記憶體片段。停止和啟動資料庫會導致停機，因此我們建議您謹慎執行此動作。