本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon Keyspaces 中的容量管理错误故障排除
在使用无服务器容量时遇到问题？ 以下介绍一些常见问题以及如何解决这些问题。
## 无服务器容量错误
本节简要介绍如何识别与无服务器容量管理相关的错误以及如何解决这些错误。例如，如果您的应用程序超出了预置的吞吐能力，则可能会发现容量不足事件。
由于 Apache Cassandra 是基于集群的软件，专为在节点队列上运行而设计，因此它没有与无服务器功能（例如吞吐能力）相关的异常消息。大多数驱动程序只能理解 Apache Cassandra 中的错误代码，因此 Amazon Keyspaces 使用相同的错误代码集来保持兼容性。
要将 Cassandra 错误映射到底层容量事件，您可以使用亚马逊 CloudWatch 监控相关的 Amazon Keyspaces 指标。导致客户端出错的容量不足事件可根据引起事件的资源分为三类：
+ **表** - 如果您为表选择**预配置**容量模式，并且您的应用程序超出了预配置的吞吐量，则可能会出现容量不足错误。有关更多信息，请参阅 [在 Amazon Keyspaces 中配置 read/write 容量模式](ReadWriteCapacityMode.md)。
+ **分区** — 如果给定分区的流量超过 3,000 或 1,000 RCUs ，则可能会遇到容量不足事件。 WCUs我们建议最佳做法是在分区之间均匀分配流量。有关更多信息，请参阅 [数据建模最佳实践：设计数据模型的建议](data-modeling.md)。
+ **连接** - 如果超过每个连接每秒最大操作次数的限额，可能会出现吞吐量不足的问题。要提高吞吐量，可以在配置与驱动程序的连接时增加默认连接的数量。
要了解如何为 Amazon Keyspaces 配置连接，请参阅[如何在 Amazon Keyspaces 中配置连接](connections.md#connections.howtoconfigure)。有关通过 VPC 端点优化连接的更多信息，请参阅[如何在 Amazon Keyspaces 中通过 VPC 端点配置连接](connections.md#connections.VPCendpoints)。
要确定是哪个资源导致了返回客户端错误的容量不足事件，可以检查 Amazon Keyspaces 控制台中的控制面板。**默认情况下，控制台在该表的 “容量” 选项卡的 “容量和相关 CloudWatch 指标” 部分中提供最常见**容量和流量相关指标**的汇总视图。**
要使用亚马逊创建自己的控制面板 CloudWatch，请查看以下 Amazon Keyspaces 指标。
+ `PerConnectionRequestRateExceeded` – 向 Amazon Keyspaces 发出的超出了每个连接请求速率的限额。与 Amazon Keyspaces 的每个客户端连接每秒最多可支持 3000 个 CQL 请求。通过创建多个连接，每秒可以执行超过 3000 个请求。
+ `ReadThrottleEvents` – 对 Amazon Keyspaces 的请求超过了表的读取容量。
+ `StoragePartitionThroughputCapacityExceeded` — 对 Amazon Keyspaces 存储分区的请求超过了该分区的吞吐能力。Amazon Keyspaces 存储分区最多可以支持每秒 1000 个， WCU/WRU 每秒 3000 RCU/RRU 个。为了缓解这些异常情况，我们建议您检查您的数据模型，以便将 read/write 流量分配到更多分区。
+ `WriteThrottleEvents` – 对 Amazon Keyspaces 的请求超过了表的写入容量。
要了解更多信息 CloudWatch，请参阅[使用亚马逊监控亚马逊密钥空间 CloudWatch](monitoring-cloudwatch.md)。有关 Amazon Keyspaces 的所有可用 CloudWatch 指标的列表，请参阅。[Amazon Keyspaces 指标与维度](metrics-dimensions.md)
**注意**
[要开始使用显示 Amazon Keyspaces 所有常见指标的自定义控制面板，您可以使用示例存储库 GitHub 中提供的预建 CloudWatch 模板。AWS](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates)
**Topics**
+ [客户端错误](#troubleshooting.serverless.clientside)
+ [数据导入期间出现写入超时错误](#troubleshooting.serverless.writetimeout)
+ [键空间或表的存储大小](#troubleshooting.serverless.storagesize)
### 我从客户端驱动程序接收到 `NoHostAvailable` 容量不足的错误
**您看到某个表出现 `Read_Timeout` 或 `Write_Timeout` 异常。**
重复尝试向容量不足的 Amazon Keyspaces 表写入或读取数据，可能会导致特定于驱动程序的客户端错误。
CloudWatch 用于监控您的预配置吞吐量和实际吞吐量指标，以及表的容量不足事件。例如，读取请求如果没有足够的吞吐容量，就会出现 `Read_Timeout` 异常，并发布到 `ReadThrottleEvents` 指标。写入请求如果没有足够的吞吐容量，就会出现 `Write_Timeout` 异常，并发布到 `WriteThrottleEvents` 指标。有关这些指标的更多信息，请参阅 [Amazon Keyspaces 指标与维度](metrics-dimensions.md)。
请考虑使用以下选项之一来解决这些问题：
+ 增加表的*预置吞吐量*，即应用程序可消耗的最大吞吐能力。有关更多信息，请参阅 [读取容量单位和写入容量单位](ReadWriteCapacityMode.Provisioned.md#ReadWriteCapacityMode.Provisioned.Units)。
+ 让该服务通过自动扩展代表您管理吞吐能力。有关更多信息，请参阅 [使用 Amazon Keyspaces 自动扩缩自动管理吞吐能力](autoscaling.md)。
+ 为表选择**按需**容量模式。有关更多信息，请参阅 [配置按需容量模式](ReadWriteCapacityMode.OnDemand.md)。
如果您需要增加账户的默认容量限额，请参阅 [Amazon Keyspaces（Apache Cassandra 兼容）限额](quotas.md)。
**您看到与超出分区容量相关的错误。**
当您看到错误 `StoragePartitionThroughputCapacityExceeded` 时，代表分区容量暂时超过了。这可能会由自适应容量或按需容量自动处理。我们建议您检查您的数据模型，将 read/write 流量分配到更多分区，以缓解这些错误。Amazon Keyspaces 存储分区最多可以支持每秒 1000 个， WCU/WRU 每秒 3000 RCU/RRU 个。要详细了解如何改进数据模型以将 read/write 流量分配到更多分区，请参阅[数据建模最佳实践：设计数据模型的建议](data-modeling.md)。
`Write_Timeout` 异常也可能是由于在同一逻辑分区中包含静态和非静态数据的并发写入操作速率过高造成的。如果预计流量会在同一逻辑分区中运行多个包含静态和非静态数据的并发写入操作，我们建议将静态和非静态数据分别写入。分别写入数据还有助于优化吞吐量成本。
**您看到与超出连接请求速率相关的错误。**
您看到的 `PerConnectionRequestRateExceeded` 是因为以下原因之一而引起。
+ 您可能没有为每个会话配置足够的连接。
+ 由于没有正确配置 VPC 端点权限，获得的连接可能少于可用的对等节点。有关 VPC 端点策略的更多信息，请参阅[将接口 VPC 端点用于 Amazon Keyspaces](vpc-endpoints.md#using-interface-vpc-endpoints)。
+ 如果使用的是 4.x 驱动程序，请检查是否启用了主机名验证。默认情况下，该驱动程序启用 TLS 主机名验证。此配置会导致 Amazon Keyspaces 在驱动程序中显示为单节点集群。我们建议您关闭主机名验证。
我们建议您遵循以下最佳实践，以确保优化连接和吞吐量：
+ **配置 CQL 查询吞吐量调整。**
Amazon Keyspace 支持每个 TCP 连接每秒最多 3,000 次 CQL 查询，但对驱动程序可建立的连接数没有限制。
大多数开源 Cassandra 驱动程序都会建立一个连接到 Cassandra 的连接池，并在该连接池上对查询进行负载均衡。Amazon Keyspaces 向驱动程序公开 9 个对等 IP 地址。大多数驱动程序的默认行为是为每个对等 IP 地址建立一个连接。因此，使用默认设置的驱动程序的最大 CQL 查询吞吐量将是每秒 27,000 次 CQL 查询。
要增大此数字，我们建议增加驱动程序在其连接池中维护的每个 IP 地址的连接数。例如，如果将每个 IP 地址的最大连接数设置为 2，则将使驱动程序的最大吞吐量增加一倍，达到每秒 54,000 次 CQL 查询。
+ **优化您的单节点连接。**
默认情况下，大多数开源 Cassandra 驱动程序在建立会话时会与 `system.peers` 表中公布的每个 IP 地址建立一个或多个连接。但是，某些配置可能会导致驱动程序连接到单个 Amazon Keyspaces IP 地址。如果驱动程序尝试对对等节点（例如 DataStax Java 驱动程序）进行 SSL 主机名验证，或者通过 VPC 终端节点进行连接，则可能会发生这种情况。
要获得与连接到多个 IP 地址的驱动程序相同的可用性和性能，建议您执行以下操作：
+ 根据所需的客户端吞吐量，将每个 IP 的连接数增加到 9 或更高。
+ 创建自定义重试策略，确保针对同一个节点运行重试。有关更多信息，请参阅
[如何在 Amazon Keyspaces 中配置连接的重试策略](connections.md#connections.retry-policies).
+ 如果使用 VPC 端点，请向用于连接 Amazon Keyspaces 的 IAM 实体授予访问权限，以查询您的 VPC 的端点和网络接口信息。这改善了负载平衡并增加了 read/write 吞吐量。有关更多信息，请参阅 [使用接口 VPC 端点信息填充 `system.peers` 表条目](vpc-endpoints.md#system_peers)。
### 我在数据导入期间收到写入超时错误
**使用 `cqlsh` `COPY` 命令上传数据时，您收到超时错误。**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces 使用 `ReadTimeout` 和 `WriteTimeout` 异常指示写入请求何时因吞吐容量不足而失败。为了帮助诊断容量不足异常，Amazon Keyspaces 在亚马逊上发布了以下指标。 CloudWatch
+ `WriteThrottleEvents`
+ `ReadThrottledEvents`
+ `StoragePartitionThroughputCapacityExceeded`
要解决数据加载期间容量不足的错误，请降低每个工作线程的写入速率或总摄取速率，然后重试上传各行。有关更多信息，请参阅 [步骤 4：配置 `cqlsh COPY FROM` 设置](bulk-upload-config.md)。要获得更强大的数据上传选项，可以考虑使用 DSBulk[GitHub 存储库](https://github.com/datastax/dsbulk)中提供的选项。有关 step-by-step说明，请参阅[教程：使用将数据加载到 Amazon Keyspaces DSBulk](dsbulk-upload.md)。
### 我看不到键空间或表的实际存储大小
**您看不到键空间或表的实际存储大小。**
要了解有关表存储容量的更多信息，请参阅[在表级别评估您的成本](CostOptimization_TableLevelCostAnalysis.md)。您还可以通过计算表中的行大小来估算存储大小。有关计算行大小的详细说明，请参阅[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。