Amazon Managed Service for Apache Flink 之前称为 Amazon Kinesis Data Analytics for Apache Flink。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
性能故障排除
本节包含症状列表，您可以通过检查这些症状来诊断和修复性能问题。
如果您的数据源是 Kinesis 流，则性能问题通常表现为较高或不断增加millisbehindLatest的指标。对于其他来源，您可以查看类似的指标，该指标表示从源读取延迟。
数据路径
在调查应用程序的性能问题时，请考虑数据所走的整个路径。如果设计或配置不当，以下应用程序组件可能会成为性能瓶颈并造成背压：
数据源和目标：确保您的应用程序与之交互的外部资源是针对您的应用程序将要经历的吞吐量预置的。
状态数据：确保您的应用程序不会过于频繁地与状态存储交互。
您可以优化您的应用程序正在使用的串行器。默认的 Kryo 串行器可以处理任何可序列化类型，但是如果您的应用程序仅以 POJO 类型存储数据，则可以使用性能更高的串行器。有关 Apache Flink 串行器的信息，请参阅 Apache Flink 文档
中的数据类型和序列化 。 运算符：确保运算符实现的业务逻辑不会太复杂，或者在处理每条记录时都不会创建或使用资源。还要确保您的应用程序不会过于频繁地创建滑动或滚动窗口。
性能故障排除解决方案
本节包含性能问题的潜在解决方案。
CloudWatch 监控级别
确认 CloudWatch 监控级别的设置是否设置得过于冗长。
Debug监控日志级别设置会生成大量流量，这可能会造成背压。只有在积极调查应用程序问题时才应使用它。
如果您的应用程序Parallelism设置为高，则使用
Parallelism监控指标级别同样会生成大量流量，从而导致背压。仅当Parallelism您的应用程序较低或在调查应用程序问题时，才使用此指标级别。
有关更多信息，请参阅应用程序监控级别。
应用程序 CPU 指标
检查应用程序的CPU指标。如果该指标高于 75%，则可以通过启用 auto Scaling 来允许应用程序为自己分配更多资源。
如果启用了 auto Scaling，则如果 CPU 使用率在 15 分钟内超过 75%，则应用程序会分配更多资源。有关扩展的更多信息，请参阅以下正确管理扩展部分和 扩展。
注意
应用程序只会根据 CPU 使用率自动扩展。应用程序不会自动缩放以响应其他系统指标，例如heapMemoryUtilization。如果您的应用程序对其他指标的使用率很高，请手动提高应用程序的并行度。
应用程序并行度
增加应用程序的并行度。您可以使用 更新应用程序 操作的ParallelismConfigurationUpdate参数更新应用程序的并行度。
应用程序的最大 KPU 默认为 64 个，可以请求增加限制以增加该数值。
还必须根据每个运算符的工作负载为其分配并行度，而不仅仅是增加应用程序并行度。参见运算符并行度下文。
应用程序日志记录
检查应用程序是否为处理的每个记录写入一个条目。在应用程序具有较高的吞吐量时，为每个记录写入一个日志条目将导致严重的数据处理瓶颈。要检查这种情况，请查询日志以查找应用程序为它处理的每个记录写入的日志条目。有关创建新应用程序的更多信息，请参阅使用日志见解分析 CloudWatch 日志。
运算符并行度
确认您的应用程序的工作负载在工作进程之间均匀分配。
有关调整应用程序运算符工作负载的信息，请参阅运算符扩展。
应用程序逻辑
检查应用程序逻辑以查找效率低下或性能不佳的操作，例如，访问外部依赖项（如数据库或 Web 服务），访问应用程序状态，等等。如果外部依赖关系性能不佳或无法可靠访问，也会影响性能，这可能会导致外部依赖项返回错误HTTP 500。
如果您的应用程序使用外部依赖项以丰富或以其他方式处理传入数据，请考虑改用异步 IO。有关更多信息，请参阅《Apache Flink 文档》
应用程序内存
检查您的应用程序是否存在资源泄漏。如果您的应用程序未正确处置线程或内存，则可能会看到millisbehindLatestCheckpointSize、和CheckpointDuration指标激增或逐渐增加。这种情况也可能导致任务管理器或任务管理器失败。