性能排除 - Amazon Kinesis Data Analytics
数据路径性能和问题排查
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

性能排除

本部分包含症状列表，您可以检查这些症状以诊断和修复性能问题。

如果您的数据源是 Kinesis 流，则性能问题通常表现为MillisBehindLatest指标过高或不断增加。对于其他来源，您可以查看表示从源读取延迟的类似指标。

数据路径

在调查应用程序的性能问题时，请考虑数据的整个路径。如果设计或配置不当，以下应用程序组件可能会成为性能瓶颈并造成背压：

  • 数据源和目的地：确保您的应用程序与之交互的外部资源是为您的应用程序将体验的吞吐量配置的属性。

  • 状态数据：确保您的应用程序不会过于频繁地与状态存储交互。

    你可以优化你的应用程序正在使用的序列化器。默认的 Kryo 序列化器可以处理任何可序列化类型，但如果您的应用程序仅以 POJO 类型存储数据，则可以使用性能更高的序列化器。有关 Apache Flink 序列化器的信息，请参阅 Apache Flink 文档中的数据类型和序列化。

  • 运算符：确保操作员实现的业务逻辑不会过于复杂，或者您没有在处理每条记录的情况下创建或使用资源。还要确保您的应用程序不会过于频繁地创建滑动或翻滚窗口。

性能和问题排查

本节包含性能问题的潜在解决方案。

CloudWatch 监控级别

确认 CloudWatch 监控级别的设置没有过于冗长。

Debug监控日志级别设置会生成大量流量，这可能会造成反压。你应该只在积极调查应用程序问题时使用它。

如果您的应用程序Parallelism设置较高，则使用 Parallelism监控指标级别同样会生成大量流量，从而导致反压。只有在您的应用程序较低或在调查应用程序问题时才使用此指标级别。Parallelism

有关更多信息，请参阅 应用程序监控级别。

应用程序 CPU 指标

检查应用程序的CPU指标。如果此指标超过 75%，则可以通过启用 Auto Scaling 允许应用程序为自己分配更多资源。

如果启用auto 扩展，则如果 CPU 使用率在 15 分钟内超过 75%，则应用程序会分配更多资源。有关缩放的更多信息，请参阅以下正确管理扩展部分和扩缩 准备就绪。

注意

应用程序只能在响应 CPU 使用率时自动扩展。应用程序不会根据其他系统指标auto 扩展，例如heapMemoryUtilization。如果您的应用程序对其他指标的使用率很高，请手动提高应用程序的并行度。

应用程序并行选项

增加应用程序的并行度。您可以使用UpdateApplication操作的ParallelismConfigurationUpdate参数更新应用程序的并行度。

应用程序的最大 KPU 默认为 32 个，可以请求增加限制以增加该数值。

重要的是还要根据每个操作员的工作负载为其分配并行度，而不仅仅是增加应用程序的并行度。见运算符并行选项下文。

应用程序日志

检查应用程序是否为处理的每个记录写入一个条目。在应用程序具有较高的吞吐量时，为每个记录写入一个日志条目将导致严重的数据处理瓶颈。要检查这种情况，请查询日志以查找应用程序为它处理的每个记录写入的日志条目。有关读取应用程序日志的更多信息，请参阅使用日志见解分析 CloudWatch 日志。

运算符并行选项

验证应用程序的工作负载是否在工作进程之间均匀分布。

有关调整应用程序操作员工作负载的信息，请参阅操作员扩展。

应用程序逻辑

检查应用程序逻辑以查找效率低下或性能不佳的操作，例如，访问外部依赖项（如数据库或 Web 服务），访问应用程序状态，等等。如果外部依赖关系性能不佳或不可靠，也可能影响性能，这可能导致外部依赖项返回HTTP 500错误。

如果您的应用程序使用外部依赖关系来丰富或以其他方式处理传入数据，请考虑改用异步 IO。有关更多信息，请参阅 A pache Flink 文档中的异步 I/O。

应用程序内存

检查您的应用程序是否存在资源泄漏。如果您的应用程序未正确处置线程或内存，则可能会看到MillisBehindLatestCheckpointSize、和CheckpointDuration指标达到峰值或逐渐增加。这种情况也可能导致任务管理器或作业管理器故障。