本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
App Mesh 缩放疑难解答
本主题详细介绍了您在扩展 App Mesh 时可能遇到的常见问题。
将虚拟节点/虚拟网关的副本扩展到 50 个以上时，连接失败且容器运行状况检查失败
症状
当您将虚拟节点/虚拟网关的副本数量（例如 Amazon ECS 任务、Kubernetes 容器组 (pod) 或 Amazon EC2 实例）扩展到 50 以上时，Envoy 对新的和当前正在运行的 Envoy 的容器运行状况检查开始失败。向虚拟节点/虚拟网关发送流量的下游应用程序开始看到请求失败并显示 HTTP 状态码 503。
解决方案
App Mesh 对每个虚拟节点/虚拟网关的 Envoy 数量的默认配额为 50。当正在运行的 Envoy 数量超过此配额时，新的和当前正在运行的 Envoy 将无法通过 gRPC 状态码 8(RESOURCE_EXHAUSTED)连接到 App Mesh 的 Envoy 管理服务。这个配额可以提高。有关更多信息，请参阅 App Mesh 服务限额。
如果您的问题仍未解决，请考虑GitHub 提出问题
503当虚拟服务后端水平向外扩展或向内扩展时，请求会失败
症状
当后端虚拟服务横向扩展或向内扩展时，来自下游应用程序的请求会失败，并 HTTP 503 显示状态码。
解决方案
App Mesh 推荐了几种方法来缓解故障情况，同时水平扩展应用程序。有关如何防止这些故障的详细信息，请参阅 App Mesh 最佳实践。
如果您的问题仍未解决，请考虑GitHub 提出问题
在负载增加的情况下，Envoy 容器因段错误而崩溃
症状
在高流量负载下，Envoy 代理由于分段错误（Linux 退出代码 139）而崩溃。Envoy 进程日志包含如下语句。
Caught Segmentation fault, suspect faulting address 0x0"解决方案
Envoy 代理可能违反了操作系统的默认 nofile ulimit，即一个进程一次可以打开的文件数量的限制。这种漏洞是由于流量导致了更多的连接，从而消耗了额外的操作系统插槽。要解决此问题，请增加主机操作系统上的 ulimit nofile 值。如果您使用的是 Amazon ECS，则可以通过任务定义的资源限制设置上的 Ulimit 设置来更改此限制。
如果您的问题仍未解决，请考虑GitHub 提出问题
默认资源的增加未反映在服务限制中
症状
在增加 App Mesh 资源的默认限制后，当您查看服务限制时，新值不会反映出来。
解决方案
虽然目前未显示新的限制，但客户仍然可以行使这些限制。
如果您的问题仍未解决，请考虑GitHub 提出问题
由于大量的运行状况检查调用，应用程序崩溃。
症状
为虚拟节点启用主动运行状况检查后，运行状况检查调用的数量会增加。由于向应用程序发出的运行状况检查调用的数量大大增加，应用程序崩溃。
解决方案
启用主动运行状况检查后，下游（客户端）的每个 Envoy 端点都会向上游集群（服务器）的每个端点发送运行状况请求，以便做出路由决策。因此，运行状况检查请求的总数将为 number of
client Envoys * number of server Envoys * active health check
frequency。
要解决此问题，请修改运行状况检查探测器的频率，这将减少运行状况检查探测器的总量。除了主动运行状况检查外，App Mesh 还允许将异常值检测配置为被动运行状况检查的手段。使用异常值检测来配置何时根据连续5xx响应移除特定主机。
如果您的问题仍未解决，请考虑GitHub 提出问题