1.性能调优（Performance Tuning）

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

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

1.1.性能故障排除指南（Performance Troubleshooting Guide）

您可以使用此疑难解答指南快速诊断和解决Logstash性能问题。不需要高级的管道内部知识就可以理解本指南。但是，如果您想超越本指南，建议阅读 pipeline documentation。

作为提高性能的第一次尝试，您可能会想跳楼并更改诸如 pipe.workers（-w）之类的设置。根据我们的经验，更改此设置会使解决性能问题更加困难，因为您会增加正在使用的变量的数量。而是一次进行一次更改并衡量结果。从此列表的末尾开始是确定情况的可靠方法。

1.1.1.绩效检查表（Performance Checklist）

检查输入源和输出目标的性能：
1. Logstash仅与其连接的服务一样快。 Logstash仅能以其输入和输出目的地的速度消耗和产生数据！
查看系统统计信息：
1. CPU
  1. 请注意CPU是否被大量使用。在Linux / Unix上，您可以运行top -H来查看按线程划分的进程统计信息以及总CPU统计信息。
  2. 如果CPU使用率很高，请跳至有关检查JVM堆的部分，然后阅读有关调整Logstash worker设置的部分。
2. Memory
  1. 请注意Logstash在Java VM上运行的事实。这意味着Logstash将始终使用您分配给它的最大内存量。
  2. 寻找其他使用大量内存并可能导致Logstash交换到磁盘的应用程序。如果应用程序使用的总内存超过物理内存，则会发生这种情况。
3. I/O Utilization
  1. 监视磁盘I / O以检查磁盘是否饱和。
    1. 如果您使用的Logstash插件（例如文件输出）可能会使存储空间饱和，则可能导致磁盘饱和。
    2. 如果遇到很多错误，这些错误迫使Logstash生成大量错误日志，则磁盘饱和也可能发生。
    3. 在Linux上，可以使用iostat，dstat或类似的工具来监视磁盘I / O。
  2. 监视网络I / O的网络饱和度。
    1. 如果您使用执行大量网络操作的输入/输出，则可能会发生网络饱和。
    2. 在Linux上，您可以使用dstat或iftop之类的工具来监视网络。
4. 检查JVM堆：
  1. 如果堆大小太低，CPU利用率通常会飞速增长，从而导致JVM不断进行垃圾收集。
  2. 检查此问题的快速方法是将堆大小加倍，并查看性能是否有所提高。不要增加堆大小超过物理内存量。为操作系统和其他进程留出至少1GB的可用空间。
  3. 您可以使用与Java一起分发的jmap命令行实用程序或使用VisualVM对JVM堆进行更准确的测量。有关更多信息，请参见 Profiling the Heap。
  4. 始终确保将最小（Xms）和最大（Xmx）堆分配大小设置为相同的值，以防止在运行时调整堆大小，这是一个非常昂贵的过程。
5. 调整Logstash工作程序设置：
  1. 首先使用-w标志扩大管道工人的数量。这将增加可用于过滤器和输出的线程数。如果需要，可以安全地将其扩展到多个CPU内核，因为线程可以在I / O上变为空闲状态。
  2. 您也可以调整输出批次大小。对于许多输出，例如Elasticsearch输出，此设置将对应于I / O操作的大小。对于Elasticsearch输出，此设置对应于批次大小。

1.2.调整和分析Logstash性能（Tuning and Profiling Logstash Performance）

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

修改这些选项之前，请确保已阅读《性能故障排除指南》（Performance Troubleshooting Guide）。

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

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

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

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

1.2.2.分析堆

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

Logstash【从无到有从有到无】【L13】性能调优

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

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

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