本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
排查性能方
本节包含一个症状列表，您可以检查这些症状以诊断和修复性能问题。
如果您的数据源是 Kinesis 流，则性能问题通常表现为高或不断增加MillisBehindLatest指标。对于其他来源，您可以检查表示从源读取滞后的类似指标。
数据路径
在调查应用程序的性能问题时，请考虑数据所采用的整个路径。如果设计或配置不正确，以下应用程序组件可能会成为性能瓶颈并造成背压：
数据源和目标：确保应用程序与之交互的外部资源为应用程序将体验的吞吐量配置了属性。
状态数据：确保您的应用程序不会频繁与州商店进行交互。
您可以优化应用程序正在使用的序列化器。默认的 Kryo 序列化器可以处理任何可序列化的类型，但是如果应用程序仅以 POJO 类型存储数据，则可以使用更高性能的序列化器。有关 Apache Flink 序列化器的信息，请参阅数据类型和序列化
中的Apache Flink 文档 . 运算符：确保运营商实施的业务逻辑不会太复杂，或者您在处理每条记录时没有创建或使用资源。还要确保您的应用程序不会过于频繁地创建滑动或翻滚窗口。
性能故障排除解
本节包含性能问题的潜在解决方案。
CloudWatch 监控级别
验证 CloudWatch 监控级别没有设置为过于冗长设置。
这些区域有：Debug监视日志级别设置会产生大量流量，这可能会造成背压。只有在积极调查应用程序的问题时才能使用它。
如果你的应用程序有很高Parallelism设置，请使用
Parallelism监控指标级别同样会产生大量流量，从而导致背压。仅在以下情况下使用此指标级Parallelism因为你的应用程序不足，或者在调查应用程序的问题时。
有关更多信息，请参阅 应用程序监控级别。
应用程序 CPU 指标
检查应用程序的CPU指标。如果此指标超过 75％，则可以通过启用 auto 扩展来允许应用程序为自己分配更多资源。
如果启用了 auto 扩展，如果 CPU 使用率在 15 分钟内超过 75％，则应用程序会分配更多资源。有关扩展的更多信息，请参阅正确管理扩展下面的部分，以及扩缩 准备就绪.
应用程序只会根据 CPU 使用情况自动扩展。应用程序不会 auto 扩展以响应其他系统指标，例如heapMemoryUtilization. 如果您的应用程序对其他指标的使用率很高，请手动提高应用程序的并行度。
应用程序并行度
增加应用程序的并行度。您可以使用ParallelismConfigurationUpdate的参数UpdateApplicationaction.
应用程序的最大 KPU 默认为 32 个，可以请求增加限制以增加该数值。
还必须根据每个运营商的工作负载为其分配并行性，而不仅仅是增加应用程序并行度。请参阅运算符并行度以下。
应用程序记
检查应用程序是否为处理的每个记录写入一个条目。在应用程序具有较高的吞吐量时，为每个记录写入一个日志条目将导致严重的数据处理瓶颈。要检查这种情况，请查询日志以查找应用程序为它处理的每个记录写入的日志条目。有关读应用程序日志的更多信息，请参阅使用分析日志 CloudWatch 日志分析.
运算符并行度
验证是否在工作进程中均匀分配应用程序的工作负载。
有关调整应用程序操作员工作负载的信息，请参阅运营商扩展.
应用逻辑
检查应用程序逻辑以查找效率低下或性能不佳的操作，例如，访问外部依赖项（如数据库或 Web 服务），访问应用程序状态，等等。如果外部依赖关系不是性能或不可靠地访问，也可能会阻碍性能，这可能会导致外部依赖关系退出HTTP 500错误消息。
如果应用程序使用外部依赖项以丰富或以其他方式处理传入数据，请考虑改用异步 IO。有关更多信息，请参阅 。异步 I/O
应用程序存
检查应用程序是否有资源泄漏。如果你的应用程序没有正确处置线程或内存，你可能会看到MillisBehindLatest、CheckpointSize, 和CheckpointDuration指标激增或逐渐增加。这种情况也可能导致任务管理器或作业管理器失败。