logstash7.10-性能调优（官网）

本节包含有关调整Logstash性能的信息：

• 性能故障排除
• 调整和分析Logstash性能

 

性能故障排除

您可以使用这些故障排除提示来快速诊断和解决Logstash性能问题。不需要高级的管道内部知识就可以理解本指南。但是，如果您想超越这些技巧，建议阅读管道文档。

您可能会很想修改pipeline.workers （-w）之类的配置，这是提高性能的第一次尝试。根据我们的经验，修改此配置会使性能问题变得更加困难，因为您在增加变数。最好就是使用控制变量法，一次修改一个配置然后确定结果。建议看完本文，才不会导致因为乱改配置导致异常出现。

1. 检查输入源和输出目标的性能：

   • Logstash仅与其连接的服务一样快。Logstash仅能以其输入和输出目的地的速度消耗和产生数据！

2. 查看系统统计信息：

   • CPU

     • 请注意CPU是否被大量使用。在Linux / Unix上，您可以运行top -H以查看按线程划分的进程统计信息以及总CPU统计信息。
     • 如果CPU使用率很高，请跳至有关检查JVM堆的部分，然后阅读有关调整Logstash worker设置的部分。

   • 内存

     • 请注意Logstash在Java VM上运行的事实。这意味着Logstash将始终使用分配给它的最大内存量。
     • 寻找其他使用大量内存并可能导致Logstash交换到磁盘的应用程序。如果应用程序使用的总内存超过物理内存，则会发生这种情况。

   • I / O利用率

     • 监视磁盘I / O检查磁盘是否饱和。

       • 如果您使用的Logstash插件（例如文件输出）可能会使存储饱和，则可能导致磁盘饱和。
       • 如果遇到很多错误，这些错误迫使Logstash生成较大的错误日志，则磁盘饱和也可能发生。
       • 在Linux上，可以使用iostat，dstat或类似的工具监视磁盘I / O。

     • 监视网络I / O的网络饱和度。

       • 如果您使用执行大量网络操作的输入/输出，则可能发生网络饱和。
       • 在Linux上，您可以使用dstat或iftop之类的工具来监视网络。

3. 检查JVM堆：

   • 对于典型的方案，建议的堆大小应不小于4GB且不大于8GB。
   • 如果堆大小太低，CPU利用率可能会不必要地增加，从而导致JVM不断进行垃圾回收。您可以通过加倍堆大小来检查此问题，以查看性能是否有所提高。
   • 不要增加堆大小超过物理内存量。必须保留一些内存以运行OS和其他进程。作为大多数安装的一般准则，不要超过物理内存的50-75％。您拥有的内存越多，可以使用的百分比就越高。
   • 将最小（Xms）和最大（Xmx）堆分配大小设置为相同的值，以防止在运行时调整堆大小，这是一个非常昂贵的过程。
   • 您可以使用jmap随Java一起分发的命令行实用程序或使用VisualVM对JVM堆进行更准确的测量 。有关更多信息，请参见分析堆。

4. 调整Logstash管道线程配置：

   • 首先使用该-w命令扩大管道线程的数量。这将增加可用于filters和output的线程数。如果需要，因为线程可以在I / O上变为空闲状态,可以安全地将其扩展到多个CPU内核。
   • 您也可以调整output batch size。对于许多output，例如Elasticsearch output，此设置将对应于I / O操作的大小。对于Elasticsearch output，此设置对应于output batch size。

调整和分析Logstash性能

选择Logstash默认值可为大多数用户提供快速，安全的性能。但是，如果发现性能问题，则可能需要修改一些默认设置。Logstash提供了调整管道性能以下配置选项：pipeline.workers，pipeline.batch.size，和pipeline.batch.delay。有关设置这些选项的更多信息，请参见logstash.yml。

修改这些选项之前，请确保已阅读《性能疑难解答》。

• 该pipeline.workers设置确定要运行多少个线程以进行过滤和输出处理。如果发现事件正在备份，或者CPU未饱和，请考虑增加此参数的值以更好地利用可用的处理能力。甚至可以找到良好的结果，使该数目超过可用处理器的数目，因为在写入外部系统时，这些线程可能在I / O等待状态中花费大量时间。此参数的合法值为正整数。
• 该pipeline.batch.size设置定义单个工作线程在尝试执行过滤器和输出之前收集的最大事件数。较大的批处理大小通常更有效，但会增加内存开销。某些硬件配置要求您增加jvm.options配置文件中的JVM堆空间，以避免性能下降。（有关更多信息，请参阅Logstash配置文件。）由于频繁的垃圾回收或与内存不足异常相关的JVM崩溃，超出最佳范围的值会导致性能下降。输出插件可以将每个批次作为逻辑单元进行处理。例如，Elasticsearch输出为收到的每个批次发出批量请求。调优pipeline.batch.size 设置可调整发送到Elasticsearch的批量请求的大小。
• 该pipeline.batch.delay设定很少需要进行调整。此设置调整Logstash管道的延迟。管道批处理延迟是Logstash在当前管道工作线程中接收到事件后等待新消息的最长时间（以毫秒为单位）。经过这段时间后，Logstash开始执行过滤器和输出。Logstash在接收事件和在过滤器中处理该事件之间等待的最长时间是pipeline.batch.delay和 pipeline.batch.size设置的乘积。

有关管道配置和性能的说明

如果您打算修改默认管道设置，请考虑以下建议：

• 飞行中事件的总数由pipeline.workers和pipeline.batch.size设置的乘积确定 。此产品称为机上计数。调整pipeline.workers和pipeline.batch.size设置时，请记住飞行中的值。以不规则的间隔间歇地接收大型事件的管道需要足够的内存来处理这些峰值。在jvm.options配置文件中相应地设置JVM堆空间。（有关更多信息，请参见Logstash配置文件。）
• 测量每个更改，以确保提高而不是降低性能。
• 确保您留有足够的内存来应对事件大小的突然增加。例如，一个生成异常的应用程序表示为大块的文本。
• 可以将工作程序数设置为高于CPU内核数，因为输出通常会在I / O等待条件下花费空闲时间。
• Java中的线程有名字，你可以使用jstack，top和VisualVM的图形化工具来找出哪些资源给定的线程使用。
• 在Linux平台上，Logstash用描述性的东西标记它可以使用的所有线程。例如，输入显示为[base]<inputname，而管道工作程序显示为[base]>workerN，其中N是整数。如果可能，还标记其他线程以帮助您确定它们的用途。

分析堆

调整Logstash时，您可能必须调整堆大小。您可以使用VisualVM工具来分析堆。“监视器”窗格对于检查堆分配是否足以满足当前工作负载特别有用。下面的屏幕截图显示了示例Monitor窗格。第一个窗格检查配置了太多机上事件的Logstash实例。第二个窗格检查配置有适当数量的飞行事件的Logstash实例。请注意，此处使用的特定批处理大小很可能不适用于您的特定工作负荷，因为Logstash的内存需求在很大程度上取决于您发送的消息的类型。

在第一个示例中，我们看到CPU的使用效率不是很高。实际上，JVM常常不得不为“完整GC”而停止VM。完全垃圾回收是内存压力过大的常见症状。这在CPU图表上的尖峰模式中可见。在配置效率更高的示例中，GC图形模式更加平滑，并且CPU的使用方式更加统一。您还可以看到分配的堆大小和允许的最大堆大小之间有足够的空间，从而为JVM GC提供了很大的工作空间。

使用与出色的VisualGC插件类似的工具检查深入的GC统计数据，表明与在资源密集型的Old Gen“ Full” GC中花费的时间相比，过度分配的VM在高效的Eden GC中花费的时间非常少。 。

 

只要GC模式是可以接受的，偶尔增加到最大的堆大小也是可以接受的。此类堆大小峰值是响应于流水线中发生的大量事件而发生的。通常，在已使用的堆内存量和最大值之间保持一定的差距。本文档不是JVM GC调优的全面指南。阅读Oracle官方指南，以获取有关该主题的更多信息。我们还建议阅读Debugging Java Performance。