CPU 負載過重：如果 CPU 使用率持續偏高，表示執行個體大小不適合工作負載，且執行個體可能不在服務等級協議 (SLA) 的保障範圍內。Spanner CPU 使用率建議會提供容錯移轉事件的額外負擔，其中剩餘的運算資源有助於處理來自執行個體無法使用部分的流量。您可以使用 Spanner CPU 使用率指標監控 CPU 使用率。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[],[],null,["# Spanner operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for a Spanner instance to be excluded from the\nSpanner Service Level Agreement (SLA), which excludes outages\n\"caused by factors outside of Google's reasonable control\". It also provides\nguidelines on how to avoid these configurations.\n\nSpanner manages many aspects of database operations, such as\nsplitting and rebalancing data, replication, failover, and all hardware and\nsoftware updates. You can configure many of these behaviors with built-in\nsettings and administrative APIs. Your workloads also depend on other components\nin addition to Spanner, such as your applications and network.\nThese customer-controlled configurations may increase the risk of instance\ndowntime, depending on your database load and other configuration parameters.\n\nIf your instance becomes unhealthy, and if Google determines that the instance\nis out of compliance with the operational limits described on this page, then\nany resulting downtime may not be covered by (or does not count against) the\nSpanner SLA.\n| **Note:** You're responsible for monitoring your Spanner instances and verifying that they are correctly sized and configured for the type of workloads that you're running.\n\nConfigurations excluded from the Spanner SLA\n--------------------------------------------\n\nThe following configurations are excluded from the Spanner SLA:\n\n- If your instance is configured and used in a way that causes the workload to overload the instance, then it isn't covered by the SLA.\n- Downtime of instances that results from your voluntary actions or inactions isn't covered by the SLA\n- If you disable the [Spanner API](/spanner/docs/getting-started/set-up#set_up_a_project) or other Google Cloud APIs that are required to create and connect to Spanner, then it isn't covered by the SLA.\n- Unavailability of the Spanner API that is the result of your network configuration, such as proxy and firewall rules, isn't covered by the SLA.\n- Application unavailability due to out-of-date or misconfigured [clients](/spanner/docs/reference/libraries) isn't covered by the SLA. In particular, verify that you are using recent client versions with supported dependencies. For example, Java applications should use [Google's BOM](/java/docs/bom) (bill of materials) with a package manager, such as Gradle or Maven.\n\nWe recommend that you set up alerts and monitoring using\n[Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Configurations to avoid\n\nTo maintain Spanner SLA coverage, you must avoid the following\nconfigurations:\n\n- **CPU overload** : If your CPU utilization is consistently high, then your instance isn't properly sized for your workload, and the instance might not be covered by the SLA. Spanner [CPU utilization recommendations](/spanner/docs/compute-capacity#change-compute-capacity) provide overhead for a failover event, where the remaining compute resources help to accommodate traffic from unavailable parts of the instance. You can use Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) to monitor CPU utilization.\n- **Full storage** : Spanner bills you only for the storage that you use. However, each node, or unit of compute, has a [limit](/spanner/quotas#database-limits) for the amount of storage it can manage. If your instance isn't properly sized for the addressable storage per node, then the instance might not be covered by the SLA. You can use Spanner [storage utilization metrics](/spanner/docs/storage-utilization) to monitor storage utilization.\n- **Quota limit:** Node resources are limited by per-user [quotas](/spanner/quotas). Failure to request quota increases in advance might result in compute resource overload, which might not be covered by the SLA. Quota increase requests that require approval from Google are typically fulfilled within one day.\n- **Under provisioned sessions** : Spanner clients use [gRPC channels](/spanner/docs/sessions#configure_the_number_of_sessions_and_grpc_channels_in_the_pools) to communicate with Google Cloud endpoints for queries and administration. If your client environments don't provide enough channels to support the request volume of a workload, your applications might experience high latency and low request throughput that might not be covered by the SLA.\n- **Connection overload:** Many Spanner APIs can be safely retried in the event of a transient failure, such as a transaction deadlock in a query, a network issue, or rate limits for administrative APIs. Overly aggressive retries might overwhelm existing connections, causing resource exhaustion or additional throttling. The increased latency or reduced throughput might not be covered by the SLA. For more information, see [managing client timeouts and retries](/spanner/docs/custom-timeout-and-retry).\n- **Hard disk drive (HDD) overload:** [Tiered storage](/spanner/docs/tiered-storage) lets you store your Spanner data on a mix of solid-state drives (SSD) and hard disk drives (HDD). If your disk load on HDD storage reaches 100%, your Spanner instance experiences significantly increased latency and might not be covered by the SLA. You can use Spanner [tiered storage metrics](/spanner/docs/monitoring-console#tiered_storage_charts_and_metrics) to monitor disk load.\n\nWhat's next\n-----------\n\n- Learn [best practices for improving Spanner performance and availability using the launch checklist](/spanner/docs/launch-checklist)."]]
