Fluentd
1.0
1.0
  • Introduction
  • Overview
    • Life of a Fluentd event
    • Support
    • FAQ
    • Logo
    • fluent-package v5 vs td-agent v4
  • Installation
    • Before Installation
    • Install fluent-package
      • RPM Package (Red Hat Linux)
      • DEB Package (Debian/Ubuntu)
      • .dmg Package (macOS)
      • .msi Installer (Windows)
    • Install calyptia-fluentd
      • RPM Package (Red Hat Linux)
      • DEB Package (Debian/Ubuntu)
      • .dmg Package (macOS)
      • .msi Installer (Windows)
    • Install by Ruby Gem
    • Install from Source
    • Post Installation Guide
    • Obsolete Installation
      • Treasure Agent v4 (EOL) Installation
        • Install by RPM Package v4 (Red Hat Linux)
        • Install by DEB Package v4 (Debian/Ubuntu)
        • Install by .dmg Package v4 (macOS)
        • Install by .msi Installer v4 (Windows)
      • Treasure Agent v3 (EOL) Installation
        • Install by RPM Package v3 (Red Hat Linux)
        • Install by DEB Package v3 (Debian/Ubuntu)
        • Install by .dmg Package v3 (macOS)
        • Install by .msi Installer v3 (Windows)
  • Configuration
    • Config File Syntax
    • Config File Syntax (YAML)
    • Routing Examples
    • Config: Common Parameters
    • Config: Parse Section
    • Config: Buffer Section
    • Config: Format Section
    • Config: Extract Section
    • Config: Inject Section
    • Config: Transport Section
    • Config: Storage Section
    • Config: Service Discovery Section
  • Deployment
    • System Configuration
    • Logging
    • Signals
    • RPC
    • High Availability Config
    • Performance Tuning
    • Multi Process Workers
    • Failure Scenarios
    • Plugin Management
    • Trouble Shooting
    • Fluentd UI
    • Linux Capability
    • Command Line Option
    • Source Only Mode
    • Zero-downtime restart
  • Container Deployment
    • Docker Image
    • Docker Logging Driver
    • Docker Compose
    • Kubernetes
  • Monitoring Fluentd
    • Overview
    • Monitoring by Prometheus
    • Monitoring by REST API
  • Input Plugins
    • tail
    • forward
    • udp
    • tcp
    • unix
    • http
    • syslog
    • exec
    • sample
    • monitor_agent
    • windows_eventlog
  • Output Plugins
    • file
    • forward
    • http
    • exec
    • exec_filter
    • secondary_file
    • copy
    • relabel
    • roundrobin
    • stdout
    • null
    • s3
    • kafka
    • elasticsearch
    • opensearch
    • mongo
    • mongo_replset
    • rewrite_tag_filter
    • webhdfs
    • buffer
  • Filter Plugins
    • record_transformer
    • grep
    • parser
    • geoip
    • stdout
  • Parser Plugins
    • regexp
    • apache2
    • apache_error
    • nginx
    • syslog
    • ltsv
    • csv
    • tsv
    • json
    • msgpack
    • multiline
    • none
  • Formatter Plugins
    • out_file
    • json
    • ltsv
    • csv
    • msgpack
    • hash
    • single_value
    • stdout
    • tsv
  • Buffer Plugins
    • memory
    • file
    • file_single
  • Storage Plugins
    • local
  • Service Discovery Plugins
    • static
    • file
    • srv
  • Metrics Plugins
    • local
  • How-to Guides
    • Stream Analytics with Materialize
    • Send Apache Logs to S3
    • Send Apache Logs to Minio
    • Send Apache Logs to Mongodb
    • Send Syslog Data to Graylog
    • Send Syslog Data to InfluxDB
    • Send Syslog Data to Sematext
    • Data Analytics with Treasure Data
    • Data Collection with Hadoop (HDFS)
    • Simple Stream Processing with Fluentd
    • Stream Processing with Norikra
    • Stream Processing with Kinesis
    • Free Alternative To Splunk
    • Email Alerting like Splunk
    • How to Parse Syslog Messages
    • Cloud Data Logging with Raspberry Pi
  • Language Bindings
    • Java
    • Ruby
    • Python
    • Perl
    • PHP
    • Nodejs
    • Scala
  • Plugin Development
    • How to Write Input Plugin
    • How to Write Base Plugin
    • How to Write Buffer Plugin
    • How to Write Filter Plugin
    • How to Write Formatter Plugin
    • How to Write Output Plugin
    • How to Write Parser Plugin
    • How to Write Storage Plugin
    • How to Write Service Discovery Plugin
    • How to Write Tests for Plugin
    • Configuration Parameter Types
    • Upgrade Plugin from v0.12
  • Plugin Helper API
    • Plugin Helper: Child Process
    • Plugin Helper: Compat Parameters
    • Plugin Helper: Event Emitter
    • Plugin Helper: Event Loop
    • Plugin Helper: Extract
    • Plugin Helper: Formatter
    • Plugin Helper: Inject
    • Plugin Helper: Parser
    • Plugin Helper: Record Accessor
    • Plugin Helper: Server
    • Plugin Helper: Socket
    • Plugin Helper: Storage
    • Plugin Helper: Thread
    • Plugin Helper: Timer
    • Plugin Helper: Http Server
    • Plugin Helper: Service Discovery
  • Troubleshooting Guide
  • Appendix
    • Update from v0.12 to v1
    • td-agent v2 vs v3 vs v4
Powered by GitBook
On this page
  • Check your OS Configuration
  • Check top Command
  • Avoid Extra Computations
  • Use flush_thread_count Parameter
  • Use External gzip Command for S3/TD
  • Reduce Memory Usage
  • Multi-workers

Was this helpful?

  1. Deployment

Performance Tuning

PreviousHigh Availability ConfigNextMulti Process Workers

Last updated 10 months ago

Was this helpful?

This article describes how to optimize Fluentd performance within a single process. If your traffic is up to 5,000 messages/sec, the following techniques should be enough.

With more traffic, Fluentd tends to be more CPU bound. In this case, consider using feature.

Check your OS Configuration

Follow the to configure your OS properly. This can drastically improve performance, and prevent many unnecessary problems.

Check top Command

If Fluentd does not perform well as expected, check with the top command first. Try to identify which part of your system is becoming a bottleneck (CPU, Memory, Disk I/O, etc.).

Avoid Extra Computations

This is a general recommendation. It is suggested NOT TO HAVE extra computations inside Fluentd. Fluentd is flexible to do quite a bit internally, but adding too much logic to configuration file makes it difficult to read and maintain while making it less robust. The configuration file should be as simple as possible.

Use flush_thread_count Parameter

If the destination of your logs is remote storage or service, adding a flush_thread_count option will parallelize your outputs (the default is 1). Using multiple threads can hide the IO/network latency. This parameter is available for all output plugins.

<match test>
  @type output_plugin
  <buffer ...>
    flush_thread_count 8
    # ...
  </buffer>
  # ...
</match>

Note that this option does not improve the processing performance e.g. numerical computation, mutating record, etc.

Use External gzip Command for S3/TD

Ruby has GIL (Global Interpreter Lock), which allows only one thread to execute at a time. While I/O tasks can be multiplexed, CPU-intensive tasks will block other jobs. One of the CPU-intensive tasks in Fluentd is compression.

The S3/Treasure Data plugin allows compression outside of the Fluentd process, using gzip. This frees up the Ruby interpreter while allowing Fluentd to process other tasks.

# S3
<match ...>
  @type s3
  store_as gzip_command
  <buffer ...>
    flush_thread_count 8
    # ...
  </buffer>
  # ...
</match>

# Treasure Data
<match ...>
  @type tdlog
  use_gzip_command
  <buffer ...>
    flush_thread_count 8
    # ...
  </buffer>
  # ...
</match>

While not a perfect solution to leverage multiple CPU cores, this can be effective for most Fluentd deployments. As before, you can run this with flush_thread_count option as well.

Reduce Memory Usage

Here's a quote from the documentation:

Do full GC when the number of old objects is more than R * N where R is this factor and N is the number of old objects just after last full GC.

So, the default GC behavior does not call full GC until the number of old objects reaches 2.0 * before old objects. This improves the throughput but it grows the total memory usage. This setting is not good for the low resource environment e.g. a small container. For such cases, try RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.2.

Do not set a value lower than 1.0 unless there is a special reason, because there are cases where setting a value lower than 1.0 causes a performance degrade. e.g. delay of launching Fluentd.

Multi-workers

The CPU is often the bottleneck for Fluentd instances that handle billions of incoming records. To utilize multiple CPU cores, we recommend using the multi workers feature.

<system>
  workers 8
</system>

Ruby has several GC parameters to tune GC performance and you can configure these parameters via an environment variable (). To reduce memory usage, set RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR to a lower value. RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR is used for full GC trigger and the default is 2.0.

See and articles for more detail.

For more details on this feature, please read article.

If this article is incorrect or outdated, or omits critical information, please . is an open-source project under . All components are available under the Apache 2 License.

multi-worker
Pre-installation Guide
Parameter list
Ruby 2.1 Garbage Collection: ready for production
Watching and Understanding the Ruby 2.1 Garbage Collector at Work
multi process workers
let us know
Fluentd
Cloud Native Computing Foundation (CNCF)