Logstash uses 80GB of memory with pipelines and 10 configurations

A while back we had issues when we ran multiple Logstash instances, each using around 1GB of memory. We got advised to use pipelines instead. Keep in mind we are still in the POC stages, so very new to the ELK stack. We do the most basics of mistakes.

After changing to pipelines, the pipeline having around 10 configurations in it, Logstash now ends up using approx. 80GB of memory on our server.

After some research we are trying to include worker configuration in our pipeline configuration file. We are starting with 6 workers for each configuration, after reading somewhere that was a reasonable amount.

Will changing the number of worker affect the amount of memory used?
Have read that Logstash by default creates as many workers as there are cores, but if one configuration file only need 1 worker, why is the default so high?
Why would using pipelines out of the box cause Logstash to use 80GB of memory?
Is there some configuration I'm missing here that is always needed, or Logstash will just use everything the server has to offer of memory?

How did you arrive at this number of 80 GB used? Logstash memory is controlled by the jvm.options file.

The Logstash application was stopped/killed by our operations team, reporting to us that Logstash had used all of the 80GB available memory on the server. How the operations team saw this number I do not know.

Without knowing how they arrive to this number is pretty hard to understand what is the issue.

Logstash memory is controlled by the value of Xms and Xmx on the jvm.options in the config path, if you installed it using deb or rpm it will be /etc/logstash/jvm.options. Per default the value is 1 GB, so if you did not change it the logstash process will start with a 1 GB heap.

It also may use some off-heap memory in some cases, but if I'm not wrong it is also limited by the heap size, so with a 1 GB heap it would also may use another 1 GB off-heap.

All the workers in a logstash pipeline will use the same JVM heap, so if you set your pipeline to run with 8 workers and your jvm.options to 1 GB, all the 8 workers will use the same 1 GB heap, and not 1 GB per worker.

But as I said, without knowing how they arrive at that 80 GB of usages number it is pretty hard to understand what may be the issue.

Can you share your logstash.yml, pipelines.yml and your logstash configuration pipelines?

I just asked the operations team, and just got told that they know they have approx. 80 GB memory on that server, and they got alerted it was all used. So they shutdown Logstash thinking it was the problem, and then the memory got back to normal again.

So if I remember correct we have just downloaded the .tar.gz and unpacked it, run it and followed the instructions to give it SSL access to Elastic.

We run logstash with the following command starting Logstash.

./logstash --path.data /home/logstash/data-pipelines --config.reload.automatic
jvm.options do not think it is modified
## JVM configuration

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

-Xms100m
-Xmx1g

################################################################
## Expert settings
################################################################
##
## All settings below this section are considered
## expert settings. Don't tamper with them unless
## you understand what you are doing
##
################################################################

## GC configuration
11-13:-XX:+UseConcMarkSweepGC
11-13:-XX:CMSInitiatingOccupancyFraction=75
11-13:-XX:+UseCMSInitiatingOccupancyOnly

## Locale
# Set the locale language
#-Duser.language=en

# Set the locale country
#-Duser.country=US

# Set the locale variant, if any
#-Duser.variant=

## basic

# set the I/O temp directory
#-Djava.io.tmpdir=$HOME

# set to headless, just in case
-Djava.awt.headless=true

# ensure UTF-8 encoding by default (e.g. filenames)
-Dfile.encoding=UTF-8

# use our provided JNA always versus the system one
#-Djna.nosys=true

# Turn on JRuby invokedynamic
-Djruby.compile.invokedynamic=true

## heap dumps

# generate a heap dump when an allocation from the Java heap fails
# heap dumps are created in the working directory of the JVM
#-XX:+HeapDumpOnOutOfMemoryError

# specify an alternative path for heap dumps
# ensure the directory exists and has sufficient space
#-XX:HeapDumpPath=${LOGSTASH_HOME}/heapdump.hprof

## GC logging
#-Xlog:gc*,gc+age=trace,safepoint:file=@loggc@:utctime,pid,tags:filecount=32,filesize=64m

# log GC status to a file with time stamps
# ensure the directory exists
#-Xloggc:${LS_GC_LOG_FILE}

# Entropy source for randomness
-Djava.security.egd=file:/dev/urandom

# Copy the logging context from parent threads to children
-Dlog4j2.isThreadContextMapInheritable=true
pipelines.yml with censored filenames
- pipeline.id: one-pipeline
  path.config: "/home/logstash/config/one.conf"
- pipeline.id: two-pipeline
  path.config: "/home/logstash/config/two.conf"
- pipeline.id: three-pipeline
  path.config: "/home/logstash/config/three.conf"
- pipeline.id: four-pipeline
  path.config: "/home/logstash/config/four.conf"
- pipeline.id: five-pipeline
  path.config: "/home/logstash/config/five.conf"
- pipeline.id: six-pipeline
  path.config: "/home/logstash/config/six.conf"
- pipeline.id: seven-pipeline
  path.config: "/home/logstash/config/seven.conf"
- pipeline.id: eight-pipeline
  path.config: "/home/logstash/config/eight.conf"
- pipeline.id: nine-pipeline
  path.config: "/home/logstash/config/nine.conf"
- pipeline.id: ten-pipeline
  path.config: "/home/logstash/config/ten.conf"
- pipeline.id: eleven-pipeline
  path.config: "/home/logstash/config/eleven.conf"
- pipeline.id: twelve-pipeline
  path.config: "/home/logstash/config/twelve.conf"
- pipeline.id: thirteen-pipeline
  path.config: "/home/logstash/config/thirteen.conf"
- pipeline.id: fourteen-pipeline
  path.config: "/home/logstash/config/fourteen.conf"
- pipeline.id: fifteen-pipeline
  path.config: "/home/logstash/config/fifteen.conf"
- pipeline.id: sixteen-pipeline
  path.config: "/home/logstash/config/sixteen.conf"
logstash.conf exmaple - all are very similar but have differences
input {
    file {
        path => "/data/server.log"
        start_position => "end"
        stat_interval => "180 second"

        codec => multiline {
              pattern => "%{TIMESTAMP_ISO8601}\s+"
              negate => "true"
              what => "previous"
        }
     }
}
filter {
    grok {
        match => {"message" => "%{TIMESTAMP_ISO8601:logTime}\s+%{LOGLEVEL:logLevel}\s+\[%{DATA:category}\]\s+(%{DATA:thread})\s+\[%{DATA:class}\]\[%{DATA:id}\]:\s+%{GREEDYDATA:message}"}
        add_tag => ["log"]
        overwrite => ["message"]
    }
    if "LOGSTASH" in [message] {
            grok {
                match => {"message" => "LOGSTASH\s+\[ProcessorMonitor{process=%{NUMBER:process:int},\s+outputProcess=%{NUMBER:outputProcess:int},\s+storeToAtmos=%{NUMBER:storeToAtmos:int},\s+exchangeLookup=%{NUMBER:exchangeLookup:int},\s+write=%{NUMBER:write:int},\s+parse=%{NUMBER:parse:int},\s+inputFileExtractor=%{NUMBER:inputFileExtractor:int},\s+documentTypeDetection=%{NUMBER:documentTypeDetection:int},\s+fileSplitting=%{NUMBER:fileSplitting:int},\s+duplicateControl=%{NUMBER:duplicateControl:int},\s+generateAndStoreAttachment=%{NUMBER:generateAndStoreAttachment:int},\s+mergeAttachment=%{NUMBER:mergeAttachment:int},\s+convertToTiff=%{NUMBER:convertToTiff:int},\s+distributionSender=%{NUMBER:distributionSender:int}}\]\s+\[TransactionStatus{status=%{DATA:transactionStatus},\s+subStatus=%{DATA:transactionSubStatus}}\]\s+\[%{DATA:channel}\]\s+\[%{DATA:senderId}\]\s+\[%{DATA:recipientId}\]"}
                add_tag => ["stats"]
                remove_tag => ["log"]
            }
    }
    date {
        match => ["logTime", "YYYY-MM-dd;HH:mm:ss.SSS", "ISO8601"]
        timezone => "Europe/Oslo"
        target => ["logTime"]
    }
}
output {
    if "log" in [tags] {
        elasticsearch {
            hosts => ["https://xxx.xxxx.xx:9200"]
            index => "XX-log-%{+YYYY.MM.dd}"
            user => "logstash_internal"
            password => "**************"
            cacert => "/home/certs/wildcard.XXXX.xx.cert.pem"
        }
    }
    if "stats" in [tags] {
        elasticsearch {
            hosts => ["https://xxx.xxxx.xx:9200"]
            index => "XX-stats-%{+YYYY.MM.dd}"
            user => "logstash_internal"
            password => "**************"
            cacert => "/home/certs/wildcard.XXXX.xx.cert.pem"
        }
    }
}

We are now trying to configure 6 workers for each of our configurations, but if I understand you correctly that should not affect the memory usage above the default 1 GB?

It as modified, the deafult is -Xms1G and -Xmx1G, it is recommend to use the same value for both.

Yes, the heap is for the JVM process of logstash, not for each worker.

Can you share your logstash.yml ? What does your configuration looks like? Are all sixteen similar to each other? What they do? You didn't share.

From what you shared Logstash should not use more than 1 GB, do you have any logstash or system logs that would confirm that it was using 80 GB of memory?

Sorry, I attached the jvm.options when you asked for logstash.yml.
I updated my previous post to include a logstash .conf file we use. They are all very similar, using same input {} and output {}, only difference being how they grok parse the logline and reading different logfile and pointing to different indexes.

The only line in our logstash.yml which is not commented out is:

path.logs: /data/logstash/logs
logstash.yml - but mostly commented out commands/lines
# Settings file in YAML
#
# Settings can be specified either in hierarchical form, e.g.:
#
#   pipeline:
#     batch:
#       size: 125
#       delay: 5
#
# Or as flat keys:
#
#   pipeline.batch.size: 125
#   pipeline.batch.delay: 5
#
# ------------  Node identity ------------
#
# Use a descriptive name for the node:
#
# node.name: test
#
# If omitted the node name will default to the machine's host name
#
# ------------ Data path ------------------
#
# Which directory should be used by logstash and its plugins
# for any persistent needs. Defaults to LOGSTASH_HOME/data
#
# path.data:
#
# ------------ Pipeline Settings --------------
#
# The ID of the pipeline.
#
# pipeline.id: main
#
# Set the number of workers that will, in parallel, execute the filters+outputs
# stage of the pipeline.
#
# This defaults to the number of the host's CPU cores.
#
# pipeline.workers: 2
#
# How many events to retrieve from inputs before sending to filters+workers
#
# pipeline.batch.size: 125
#
# How long to wait in milliseconds while polling for the next event
# before dispatching an undersized batch to filters+outputs
#
# pipeline.batch.delay: 50
#
# Force Logstash to exit during shutdown even if there are still inflight
# events in memory. By default, logstash will refuse to quit until all
# received events have been pushed to the outputs.
#
# WARNING: Enabling this can lead to data loss during shutdown
#
# pipeline.unsafe_shutdown: false
#
# Set the pipeline event ordering. Options are "auto" (the default), "true" or "false".
# "auto" automatically enables ordering if the 'pipeline.workers' setting
# is also set to '1', and disables otherwise.
# "true" enforces ordering on the pipeline and prevent logstash from starting
# if there are multiple workers.
# "false" disables any extra processing necessary for preserving ordering.
#
# pipeline.ordered: auto
#
# Sets the pipeline's default value for `ecs_compatibility`, a setting that is
# available to plugins that implement an ECS Compatibility mode for use with
# the Elastic Common Schema.
# Possible values are:
# - disabled
# - v1
# - v8 (default)
# Pipelines defined before Logstash 8 operated without ECS in mind. To ensure a
# migrated pipeline continues to operate as it did before your upgrade, opt-OUT
# of ECS for the individual pipeline in its `pipelines.yml` definition. Setting
# it here will set the default for _all_ pipelines, including new ones.
#
# pipeline.ecs_compatibility: v8
#
# ------------ Pipeline Configuration Settings --------------
#
# Where to fetch the pipeline configuration for the main pipeline
#
# path.config:
#
# Pipeline configuration string for the main pipeline
#
# config.string:
#
# At startup, test if the configuration is valid and exit (dry run)
#
# config.test_and_exit: false
#
# Periodically check if the configuration has changed and reload the pipeline
# This can also be triggered manually through the SIGHUP signal
#
# config.reload.automatic: false
#
# How often to check if the pipeline configuration has changed (in seconds)
# Note that the unit value (s) is required. Values without a qualifier (e.g. 60) 
# are treated as nanoseconds.
# Setting the interval this way is not recommended and might change in later versions.
#
# config.reload.interval: 3s
#
# Show fully compiled configuration as debug log message
# NOTE: --log.level must be 'debug'
#
# config.debug: false
#
# When enabled, process escaped characters such as \n and \" in strings in the
# pipeline configuration files.
#
# config.support_escapes: false
#
# ------------ API Settings -------------
# Define settings related to the HTTP API here.
#
# The HTTP API is enabled by default. It can be disabled, but features that rely
# on it will not work as intended.
#
# api.enabled: true
#
# By default, the HTTP API is not secured and is therefore bound to only the
# host's loopback interface, ensuring that it is not accessible to the rest of
# the network.
# When secured with SSL and Basic Auth, the API is bound to _all_ interfaces
# unless configured otherwise.
#
# api.http.host: 127.0.0.1
#
# The HTTP API web server will listen on an available port from the given range.
# Values can be specified as a single port (e.g., `9600`), or an inclusive range
# of ports (e.g., `9600-9700`).
#
# api.http.port: 9600-9700
#
# The HTTP API includes a customizable "environment" value in its response,
# which can be configured here.
#
# api.environment: "production"
#
# The HTTP API can be secured with SSL (TLS). To do so, you will need to provide
# the path to a password-protected keystore in p12 or jks format, along with credentials.
#
# api.ssl.enabled: false
# api.ssl.keystore.path: /path/to/keystore.jks
# api.ssl.keystore.password: "y0uRp4$$w0rD"
#
# The HTTP API can be configured to require authentication. Acceptable values are
#  - `none`:  no auth is required (default)
#  - `basic`: clients must authenticate with HTTP Basic auth, as configured
#             with `api.auth.basic.*` options below
# api.auth.type: none
#
# When configured with `api.auth.type` `basic`, you must provide the credentials
# that requests will be validated against. Usage of Environment or Keystore
# variable replacements is encouraged (such as the value `"${HTTP_PASS}"`, which
# resolves to the value stored in the keystore's `HTTP_PASS` variable if present
# or the same variable from the environment)
#
# api.auth.basic.username: "logstash-user"
# api.auth.basic.password: "s3cUreP4$$w0rD"
#
# When setting `api.auth.basic.password`, the password should meet
# the default password policy requirements.
# The default password policy requires non-empty minimum 8 char string that
# includes a digit, upper case letter and lower case letter.
# Policy mode sets Logstash to WARN or ERROR when HTTP authentication password doesn't
# meet the password policy requirements.
# The default is WARN. Setting to ERROR enforces stronger passwords (recommended).
#
# api.auth.basic.password_policy.mode: WARN
#
# ------------ Module Settings ---------------
# Define modules here.  Modules definitions must be defined as an array.
# The simple way to see this is to prepend each `name` with a `-`, and keep
# all associated variables under the `name` they are associated with, and
# above the next, like this:
#
# modules:
#   - name: MODULE_NAME
#     var.PLUGINTYPE1.PLUGINNAME1.KEY1: VALUE
#     var.PLUGINTYPE1.PLUGINNAME1.KEY2: VALUE
#     var.PLUGINTYPE2.PLUGINNAME1.KEY1: VALUE
#     var.PLUGINTYPE3.PLUGINNAME3.KEY1: VALUE
#
# Module variable names must be in the format of
#
# var.PLUGIN_TYPE.PLUGIN_NAME.KEY
#
# modules:
#
# ------------ Cloud Settings ---------------
# Define Elastic Cloud settings here.
# Format of cloud.id is a base64 value e.g. dXMtZWFzdC0xLmF3cy5mb3VuZC5pbyRub3RhcmVhbCRpZGVudGlmaWVy
# and it may have an label prefix e.g. staging:dXMtZ...
# This will overwrite 'var.elasticsearch.hosts' and 'var.kibana.host'
# cloud.id: <identifier>
#
# Format of cloud.auth is: <user>:<pass>
# This is optional
# If supplied this will overwrite 'var.elasticsearch.username' and 'var.elasticsearch.password'
# If supplied this will overwrite 'var.kibana.username' and 'var.kibana.password'
# cloud.auth: elastic:<password>
#
# ------------ Queuing Settings --------------
#
# Internal queuing model, "memory" for legacy in-memory based queuing and
# "persisted" for disk-based acked queueing. Defaults is memory
#
# queue.type: memory
#
# If `queue.type: persisted`, the directory path where the pipeline data files will be stored.
# Each pipeline will group its PQ files in a subdirectory matching its `pipeline.id`.
# Default is path.data/queue.
#
# path.queue:
#
# If using queue.type: persisted, the page data files size. The queue data consists of
# append-only data files separated into pages. Default is 64mb
#
# queue.page_capacity: 64mb
#
# If using queue.type: persisted, the maximum number of unread events in the queue.
# Default is 0 (unlimited)
#
# queue.max_events: 0
#
# If using queue.type: persisted, the total capacity of the queue in number of bytes.
# If you would like more unacked events to be buffered in Logstash, you can increase the
# capacity using this setting. Please make sure your disk drive has capacity greater than
# the size specified here. If both max_bytes and max_events are specified, Logstash will pick
# whichever criteria is reached first
# Default is 1024mb or 1gb
#
# queue.max_bytes: 1024mb
#
# If using queue.type: persisted, the maximum number of acked events before forcing a checkpoint
# Default is 1024, 0 for unlimited
#
# queue.checkpoint.acks: 1024
#
# If using queue.type: persisted, the maximum number of written events before forcing a checkpoint
# Default is 1024, 0 for unlimited
#
# queue.checkpoint.writes: 1024
#
# If using queue.type: persisted, the interval in milliseconds when a checkpoint is forced on the head page
# Default is 1000, 0 for no periodic checkpoint.
#
# queue.checkpoint.interval: 1000
#
# ------------ Dead-Letter Queue Settings --------------
# Flag to turn on dead-letter queue.
#
# dead_letter_queue.enable: false

# If using dead_letter_queue.enable: true, the maximum size of each dead letter queue. Entries
# will be dropped if they would increase the size of the dead letter queue beyond this setting.
# Default is 1024mb
# dead_letter_queue.max_bytes: 1024mb

# If using dead_letter_queue.enable: true, the interval in milliseconds where if no further events eligible for the DLQ
# have been created, a dead letter queue file will be written. A low value here will mean that more, smaller, queue files
# may be written, while a larger value will introduce more latency between items being "written" to the dead letter queue, and
# being available to be read by the dead_letter_queue input when items are written infrequently.
# Default is 5000.
#
# dead_letter_queue.flush_interval: 5000

# If using dead_letter_queue.enable: true, controls which entries should be dropped to avoid exceeding the size limit.
# Set the value to `drop_newer` (default) to stop accepting new events that would push the DLQ size over the limit.
# Set the value to `drop_older` to remove queue pages containing the oldest events to make space for new ones.
#
# dead_letter_queue.storage_policy: drop_newer

# If using dead_letter_queue.enable: true, the interval that events have to be considered valid. After the interval has
# expired the events could be automatically deleted from the DLQ.
# The interval could be expressed in days, hours, minutes or seconds, using as postfix notation like 5d,
# to represent a five days interval.
# The available units are respectively d, h, m, s for day, hours, minutes and seconds.
# If not specified then the DLQ doesn't use any age policy for cleaning events.
#
# dead_letter_queue.retain.age: 1d

# If using dead_letter_queue.enable: true, defines the action to take when the dead_letter_queue.max_bytes is reached,
# could be "drop_newer" or "drop_older".
# With drop_newer, messages that were inserted most recently are dropped, logging an error line.
# With drop_older setting, the oldest messages are dropped as new ones are inserted.
# Default value is "drop_newer".
# dead_letter_queue.storage_policy: drop_newer

# If using dead_letter_queue.enable: true, the directory path where the data files will be stored.
# Default is path.data/dead_letter_queue
#
# path.dead_letter_queue:
#
# ------------ Debugging Settings --------------
#
# Options for log.level:
#   * fatal
#   * error
#   * warn
#   * info (default)
#   * debug
#   * trace
#
# log.level: info
# path.logs:
# Lgq 230329
path.logs: /data/logstash/logs
#
# ------------ Other Settings --------------
#
# Allow or block running Logstash as superuser (default: true)
# allow_superuser: false
#
# Where to find custom plugins
# path.plugins: []
#
# Flag to output log lines of each pipeline in its separate log file. Each log filename contains the pipeline.name
# Default is false
# pipeline.separate_logs: false
#
# ------------ X-Pack Settings (not applicable for OSS build)--------------
#
# X-Pack Monitoring
# https://www.elastic.co/guide/en/logstash/current/monitoring-logstash.html
#xpack.monitoring.enabled: false
#xpack.monitoring.elasticsearch.username: logstash_system
#xpack.monitoring.elasticsearch.password: password
#xpack.monitoring.elasticsearch.proxy: ["http://proxy:port"]
#xpack.monitoring.elasticsearch.hosts: ["https://es1:9200", "https://es2:9200"]
# an alternative to hosts + username/password settings is to use cloud_id/cloud_auth
#xpack.monitoring.elasticsearch.cloud_id: monitoring_cluster_id:xxxxxxxxxx
#xpack.monitoring.elasticsearch.cloud_auth: logstash_system:password
# another authentication alternative is to use an Elasticsearch API key
#xpack.monitoring.elasticsearch.api_key: "id:api_key"
#xpack.monitoring.elasticsearch.ssl.certificate_authority: "/path/to/ca.crt"
#xpack.monitoring.elasticsearch.ssl.ca_trusted_fingerprint: xxxxxxxxxx
#xpack.monitoring.elasticsearch.ssl.truststore.path: path/to/file
#xpack.monitoring.elasticsearch.ssl.truststore.password: password
#xpack.monitoring.elasticsearch.ssl.keystore.path: /path/to/file
#xpack.monitoring.elasticsearch.ssl.keystore.password: password
#xpack.monitoring.elasticsearch.ssl.verification_mode: certificate
#xpack.monitoring.elasticsearch.sniffing: false
#xpack.monitoring.collection.interval: 10s
#xpack.monitoring.collection.pipeline.details.enabled: true
#
# X-Pack Management
# https://www.elastic.co/guide/en/logstash/current/logstash-centralized-pipeline-management.html
#xpack.management.enabled: false
#xpack.management.pipeline.id: ["main", "apache_logs"]
#xpack.management.elasticsearch.username: logstash_admin_user
#xpack.management.elasticsearch.password: password
#xpack.management.elasticsearch.proxy: ["http://proxy:port"]
#xpack.management.elasticsearch.hosts: ["https://es1:9200", "https://es2:9200"]
# an alternative to hosts + username/password settings is to use cloud_id/cloud_auth
#xpack.management.elasticsearch.cloud_id: management_cluster_id:xxxxxxxxxx
#xpack.management.elasticsearch.cloud_auth: logstash_admin_user:password
# another authentication alternative is to use an Elasticsearch API key
#xpack.management.elasticsearch.api_key: "id:api_key"
#xpack.management.elasticsearch.ssl.ca_trusted_fingerprint: xxxxxxxxxx
#xpack.management.elasticsearch.ssl.certificate_authority: "/path/to/ca.crt"
#xpack.management.elasticsearch.ssl.truststore.path: /path/to/file
#xpack.management.elasticsearch.ssl.truststore.password: password
#xpack.management.elasticsearch.ssl.keystore.path: /path/to/file
#xpack.management.elasticsearch.ssl.keystore.password: password
#xpack.management.elasticsearch.ssl.verification_mode: certificate
#xpack.management.elasticsearch.sniffing: false
#xpack.management.logstash.poll_interval: 5s

# X-Pack GeoIP plugin
# https://www.elastic.co/guide/en/logstash/current/plugins-filters-geoip.html#plugins-filters-geoip-manage_update
#xpack.geoip.download.endpoint: "https://geoip.elastic.co/v1/database"

Which LS version are you using?
Do you have a screen or some trace that LS took 80 GB? RAM or disk space?
Which plugins are used in input? jdbc?

We are using Logstash version 8.6.2.
I touched on it in another reply. But I have only been told that our operations team got alerted that all memory had been used on one of our servers, which had a maximum of 80 GB of memory. They suspected Logstash being the issue and after killing/stopping Logstash the memory went back down to normal. I do sadly have no proof of this happening.

leandrojmp have already informed me that Logstash is not supposed to use more than the defined limit in jvm.options, which is for us 1 GB. So I'm thinking this was a bug, and we should try to enable Logstash again with limited workers and hope for the best. Will also ask the operations team to collect some data if this happen again.

One of our logstash .conf files are attached in a post a few post above this one.

There is only OOM in input the elasticsearch plugin fixed in LS 8.8.1.

You have 10 pipelines x 8 GB=80 GB. Maybe you should focus which plugin process so many messages at once or large message. However you can use another version.

Logstash memory is per process, not pipeline, if a logstash process is configured to run with 1 GB of heap, the multiple pipelines in pipelines.yml will share the same heap.

Also, there are 16 pipelines in the shared pipelines.yml, personally I would say that 1 GB for 16 pipelines can be pretty small and could lead to some OOM issues, but this does not seem the issue at the moment.

Until now there is no evidence that this is a bug, you need to provide some log evidences that show that logstash memory is increasing out of the configured size.

My suggestion would be:

  • Set Xms and Xmx to the same value, 1GB or maybe a little more like 2 or 4 GB
  • Do not change the number of workers, use the default.
  • Check the memory usage before starting logstash, like run some htop and take a screenshot
  • Start logstash, wait a couple of minutes and check the memory usage again.
  • Check the memory usage to see if it is increasing and what is increasing.

Are all your 16 pipelines reading files with the file input?

Yes, all 16 pipelines are file input reading different files with stat_interval => "180 second" and the codec => multiline.

I will do as you say, Start all and do a PrtScrn of the memory and monitor the memory with some print screens. Will ask the operations team to document the memory usage if they have to terminate the process again.

Thanks for all help so far.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.