Graylog日志丢失解决方案

问题描述

目前公司使用的日志方案是Graylog5.0版本，当接入的日志并发多时，就会出现日志丢失的情况。

目前硬件系统centos7.9 内核5.16.13。一台graylog和一台es服务器。

两台机器硬件配置

graylog CPU 36C 内存 150G 系统硬盘 500G （固态）

elasticsearch CPU 16C 内存 80G 系统硬盘 500G 存储硬盘 6.8T（固态）

架构图

目前公司使用的graylog架构图

架构图简述

Linux服务器及容器 通过filebeat（8.8.2）工具进行采集，日志推送到graylog的5044端口，graylog收到数据后存储到es服务器，graylog服务推送数据到logstash:12201端口 ，logstash推送到kafka服务，kafka消费数据到hive服务存储。

问题反馈

研发反馈通过graylog查询日志总是缺少几条，缺少的日志量 大概少了 3分之1 。10万条日志少了3万条日志，在流量大的时候会出现此情况。

排查思路开始，编写一个并发日志写入脚本，模拟日志大批量写入，再从客户端到服务端 逐一排查问题。

系统是centos7默认安装的是python2，模拟并发脚本就用python2编写即可。

import threading
import Queue
import time
 
class WriterThread(threading.Thread):
    def __init__(self, queue):
        threading.Thread.__init__(self)
        self.queue = queue
 
    def run(self):
        while True:
            line = self.queue.get()
            if line is None:
                break
            lock.acquire()
            try:
                with open('test.log', 'a') as f:
                    f.write(line + '\n')
            finally:
                lock.release()
            self.queue.task_done()
 
lock = threading.Lock()
queue = Queue.Queue()
 
num_threads = 10
threads = [WriterThread(queue) for _ in range(num_threads)]
for thread in threads:
    thread.start()
 
try:
    while True:
        start_time = time.time()
        for _ in range(8888):
            queue.put('0725test01')
 
        queue.join()
 
        elapsed_time = time.time() - start_time
        if elapsed_time < 1:
            time.sleep(1 - elapsed_time)
finally:
    for _ in range(num_threads):
        queue.put(None)
    for thread in threads:
        thread.join()

脚本可在服务器上直接运行，模块都是默认安装的，如需改变并发量需修改 range(8888) 改成任意值即可，如想修改输出日志内容 需修改（0725test01），运行后在脚本的同级目录会有产生一个 test.log 的文件。（这个脚本并发8888个请求）

问题一

先从连路图的最左边客户端观察，filebeat是否有丢失日志的情况。发现filebeat有丢失日志的情况。

排查filebeat服务

检查客户端filebeat下的log.json记录，发现在正常环境下日志服务正常读取，在高并发的时候，filebeat会效率很慢很卡，并发1s写8888个日志的时候服务会卡，会出现丢失日志的情况。

检查filebeat配置 代码如下：

之前 配置文件只有 两行，没有重试机制

output.logstash:
  hosts: ["graylog-server:5044"]

这里最重要的是 加入重试机制 ，失败后的重试间隔

output.logstash:
  hosts: ["graylog-server:5044"]
  workers: 4 # 增加并发工作线程数
  queue:
    events: 2000 # 增加队列中事件的数量
    length: 200 # 增加队列中批次的数量
  retry:
    on_failure: true
    backoff: 5s # 设置失败后的重试间隔
    max: 5 # 设置最大重试次数

排查filebeat服务 在高并发的情况下读取日志文件是否正常，经过测试日志数和filebeat推送的日志json数一致，确保了客户端filebeat在高并发情况下无误。

注意

filebeat的json记录了每条推送的日志 ，用rpm安装 默认位置是 /var/lib/filebeat/registry/filebeat 这里存储了json。可以查询有多少条json就可以知道filebeat是否有推送日志信息。

问题二

解决完filebeat服务后，用并发脚本测试graylog服务，发现日志还是有丢失情况，排查发现服务端CPU和内存异常高，用top等工具排查发现是logstash服务占用了资源。

排查Logstash服务

在服务端排查htop，发现logstash使用资源量比graylog还要多，而且偶现报错信息资源饱满服务卡顿，服务会异常退出，这里logstash是内存类型服务，改成了硬盘类型服务，但是web端那边查询会有较大的延迟，体验不好，开始机器内存，增加服务内存配置。同时增加消息重试机制。

监控图标

增加logstash服务的内存硬件资源

cat jvm.options 
## JVM configuration

-Xms8g
-Xmx10g

增加消息重试机制。

retries => 3   # 输出失败，则尝试最多重试 3 次
dead_letter_queue_enabled => true  # 则启用死信队列 (Dead Letter Queue, DLQ)，用于存储那些无法处理的消息。
queue_type => "memory"  # 用内存型
queue_size => 10000 # 表示队列可以容纳 10000 个事件。
backoff_strategy => "exponential"  # 表示使用指数回退策略。
backoff_max_retries => 3 # 表示在使用回退策略时最多重试 3 次。
backoff_max_delay => "10s" # 表示在使用回退策略时的最大延迟时间为 10 秒。

logstash是一个内存型的服务，这个服务默认配置内存是低于1G以下的，这里一开始怀疑是内存溢出等问题，改变了Logstash服务的模式，用了硬盘模式，把logstash服务的日志写到了硬盘上，在硬盘是做日志的持久化，把服务的消息队列写入到服务器上的一个文件上，后发现这种方法写的太慢了，web展示有很大的延迟，几乎无法正常展示了，同是增加了消息重试机制。还是要把logstash改成内存型服务，增加机器的内存。

问题三

修改完以上问题后，增加了logstash的配置，xms8g~xmx10g，后发现es的读写很高，经常卡顿，机器连接不上，排查发现es硬盘io读写很高，开始提采购更换固态硬盘6.8T硬盘。使用新的固态硬盘后 解决了es服务读写的问题（这里有人建议使用es集群，es集群是解决高可用和稳定性的，对于整体数据的读写是无法提高的。后期可以考虑使用集群，但是目前最重要的日志会写入到hive，所以目前不做es集群也不重要，只是做热数据的查询）。

排查es服务

在解决了logstash服务异常问题后，出现一个新的问题。es服务io很高，服务经常卡顿，观察资源硬盘IO经常满了，开始联系机房 更换固态硬盘。

更换固态硬盘后es读写问题解决，运行平稳。

问题四

解决以上问题后继续后高并发py脚本进行压测，发现graylog服务端依然存在丢失日志情况，开始修改graylog服务的配置，尝试解决问题。

排查graylog服务

变更server.conf的配置文件主要增加cpu配置参数 等，增加内存参数

#  /etc/graylog/server/server.conf
http_bind_address = elasticsearch-server:9000
output_batch_size = 5000
# 设置为5000表示每次向输出插件发送5000条日志数据。
output_flush_interval = 2
# 设置为2秒表示如果没有新的日志数据到来，每2秒强制刷新一次输出。
output_fault_count_threshold = 10
# 设置为2秒表示如果没有新的日志数据到来，每2秒强制刷新一次输出。
output_fault_penalty_seconds = 60
# 设置为60秒表示如果达到故障阈值，则暂停输出插件60秒。
processbuffer_processors = 30
# 设置为30表示处理缓冲区中有30个线程负责处理日志数据。
outputbuffer_processors = 30
# 设置为30表示输出缓冲区中有30个线程负责处理日志数据。
ring_size = 16777216
# 设置为16777216字节（约16MB）表示环形缓冲区的大小。
inputbuffer_ring_size = 16777216
# 设置为16777216字节（约16MB）表示输入缓冲区的环形缓冲区大小。
inputbuffer_processors = 30
# 设置为30表示输入缓冲区中有30个线程负责处理日志数据。
message_journal_enabled = true
# 设置为true表示启用消息日志功能，有助于在系统崩溃时恢复未处理的消息。
mongodb_max_connections = 1500
# 设置为1500表示MongoDB数据库的最大连接数为1500个。
input_beats_receive_buffer_size = 189582500
# 设置为189582500字节（约180MB）表示接收缓冲区的大小。

# /etc/sysconfig/graylog-server
-Xms30g -Xmx60g 

未解决问题，上面的配置未启动作用

问题五

使用高并发脚本压测，发现查询日志数和本地日志数依然不一致，观察graylog报错如下。

/var/log/graylog-server/server.log

WARN [ChunkedBulkIndexer] Bulk index failed with 'Request Entity Too Large' error. Retrying by splitting up batch size <30000>.

排查es

分析报错

报错日志和es有关，需要修改es配置文件。

Request Entity Too Large错误时，这意味着Graylog向Elasticsearch发送的批量索引请求超过了Elasticsearch允许的最大请求大小。Elasticsearch通过http.max_content_length配置项来控制允许的最大请求大小。

解决方案

变更配置文件 /etc/elasticsearch/elasticsearch.yml 重启配置

http.max_content_length: 100mb # es增加配置文件

解决此问题

问题六

使用高并发脚本压测，发现查询日志数和本地日志数依然不一致，观察graylog报错如下。

WARN [AbstractTcpTransport] receiveBufferSize (SO_RCVBUF) for input Beats2Input{title=filebeat, type=org.graylog.plugins.beats.Beats2Input, nodeId=null} (channel [id: 0x8760156e, L:/[0:0:0:0:0:0:0:0%0]:5044]) should be >= 1895825408 but is 2097152.

排查graylog

分析报错信息是 Graylog 的 Beats 输入插件 (Beats2Input) 的接收缓冲区大小 (SO_RCVBUF) 较小，而建议的接收缓冲区大小应该大于等于 1895825408 字节。这可能会导致数据包丢失或处理效率降低。

需要设置 beats_input_socket_receive_buffer_size 选项来增大接收缓冲区大小。重启服务

beats_input_socket_receive_buffer_size=209715200  # 设置为 200MB

问题七

使用高并发脚本压测，发现查询日志数和本地日志数依然不一致，观察graylog报错如下。

​2024-07-30T23:12:16.712+08:00 ERROR [ServerRuntime$Responder] An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: java.io.IOException: Connection is closed
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:67) ~[graylog.jar:?]
        at org.glassfish.jersey.message

排查graylog

这表示在尝试写入数据到网络连接时，发现连接已经关闭。这可能是由于客户端断开连接、网络故障、超时或其他原因导致的。客户端可能在服务器开始发送响应之前就已经关闭了连接。

增加配置文件 重启服务

eats_input_idle_timeout=60s  # 增加空闲超时时间

问题八

使用高并发脚本压测，发现查询日志数和本地日志数依然不一致，观察graylog报错如下。

ERROR [ServiceManager] Service LocalKafkaMessageQueueReader [FAILED] has failed in the RUNNING state.
java.lang.OutOfMemoryError: Java heap space
        at java.util.ArrayList.<init>(Unknown Source) ~[?:?

排查graylog

Graylog 服务时耗尽了可用的堆内存。这个错误通常发生在 Graylog 的 LocalKafkaMessageQueueReader 服务中。增加服务器硬件内存，增加java的内存配置，重启服务。

GRAYLOG_SERVER_JAVA_OPTS="-Xms60g -Xmx80g -server -XX:+UseG1GC"

验证并发脚本再次观察，发现查询日志数和本地日志数一致。

又引发出来一个新的问题，graylog服务运行过程中，在未来的某一个随机时间会服务宕机。

问题九

新的问题报错描述：

web端查询不到日志，kafka那边也没有任何推送日志。

服务器日志端：报错日志

ERROR [ServiceManager] Service LocalKafkaMessageQueueReader [FAILED] has failed in the RUNNING state.
java.lang.OutOfMemoryError: Java heap space
        at java.util.ArrayList.<init>(Unknown Source) ~[?:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.read(LocalKafkaJournal.java:663) ~[graylog.jar:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.readNext(LocalKafkaJournal.java:619) ~[graylog.jar:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.read(LocalKafkaJournal.java:601) ~[graylog.jar:?]
        at org.graylog2.shared.messageq.localkafka.LocalKafkaMessageQueueReader.run(LocalKafkaMessageQueueReader.java:110) ~[graylog.jar:?]
        at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:67) [graylog.jar:?]
        at com.google.common.util.concurrent.Callables$4.run(Callables.java:121) [graylog.jar:?]
        at java.lang.Thread.run(Unknown Source) [?:?]

解决办法，目前只有重启。

排查在启动配置文件中加入gc日志

配置路径 /usr/share/graylog-server/bin/graylog-server

# Add GC logging parameters here
GRAYLOG_SERVER_JAVA_OPTS="${GRAYLOG_SERVER_JAVA_OPTS} -Xlog:gc=info,safepoint,age,remset,time,heap,metaspace:file=/var/log/graylog-server/gc.log:utctime,tags,tid,level:filecount=10,filesize=10M"

分析是graylog内部维护消息的队列，消息太多内存爆了，消费速度没写入速度快，就会内存不够用。CPU异常高。

尝试解决中：

变更server.conf配置文件，观察服务是否会挂掉。

output_batch_size = 5000
output_flush_interval = 2
output_fault_count_threshold = 10
output_fault_penalty_seconds = 60

配置文件升级

output_batch_size = 30000  # 增加批处理大小
output_flush_interval = 5  # 增加刷新间隔
output_fault_count_threshold = 20  # 增加故障阈值
output_fault_penalty_seconds = 120  # 增加故障惩罚时间

观察服务是否会在未来某一个时间宕机，修改变更配置时间，2024/07/29 20:23 等待业务反馈是否有宕机表现，服务器上检查宕机触发重启脚本已关闭。

时间08/01 09:00 服务依然挂了，上面方法未能生效。

报错日志如下：

2024-08-01T09:14:09.673+08:00 ERROR [ServiceManager] Service LocalKafkaMessageQueueReader [FAILED] has failed in the RUNNING state.
java.lang.OutOfMemoryError: Java heap space
        at java.util.ArrayList.<init>(Unknown Source) ~[?:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.read(LocalKafkaJournal.java:663) ~[graylog.jar:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.readNext(LocalKafkaJournal.java:619) ~[graylog.jar:?]
        at org.graylog2.shared.journal.LocalKafkaJournal.read(LocalKafkaJournal.java:601) ~[graylog.jar:?]
        at org.graylog2.shared.messageq.localkafka.LocalKafkaMessageQueueReader.run(LocalKafkaMessageQueueReader.java:110) ~[graylog.jar:?]
        at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:67) [graylog.jar:?]
        at com.google.common.util.concurrent.Callables$4.run(Callables.java:121) [graylog.jar:?]
        at java.lang.Thread.run(Unknown Source) [?:?]

尝试解决这个问题

1、调整消息队列的大小限制来减少内存使用

journal_max_file_size_bytes=104857600 # 100 MB
journal_max_total_size_bytes=524288000 # 500 MB

2、增加内存

GRAYLOG_SERVER_JAVA_OPTS="-Xms70g -Xmx80g -server -XX:+UseG1GC"

服务目前运行良好，2024/8/1 09:40 观察服务是否能正常运行。

问题十

日志信息：

2024-08-01T16:58:16.297+08:00 ERROR [ServiceManager] Service LocalKafkaMessageQueueReader [FAILED] has failed in the RUNNING state.
java.lang.OutOfMemoryError: Java heap space

问题描述 日志无法查看，查看右上角 in 是有数值不断写入，out 是一直变为 0 不动了。这里判断是不是 out 来不及消费了。

原有配置

connect_timeout: 1000
hostname: graylog-server
max_inflight_sends: 512
port: 12201
protocol: UDP
queue_size: 512
reconnect_delay: 500

变更配置

connect_timeout: 1000000
hostname: graylog-server
max_inflight_sends: 5120000
port: 12201
protocol: UDP
queue_size: 5120000
reconnect_delay: 500000

以上配置未能解决问题

增加graylog配置文件

message_journal_retention_time=7d
input_buffer_type=disk
input_buffer_size=10000
#indices_number_of_replicas=1
message_journal_persistence_strategy=async

问题十一

graylog卡顿报错日志

​2024-08-01T19:29:44.738+08:00 ERROR [ServerRuntime$Responder] An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: java.io.IOException: Connection is closed
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:67) ~[graylog.jar:?]
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:139) ~[graylog.jar:?]
        at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1116) ~[graylog.jar:?]

分析解决：磁盘Io异常，查看监控图

增加固态硬盘，更换graylog写入的路径/data

（这里会把Graylog服务会把接受到的消息，无法及时处理的消息，先存储到这个目录里）

data_dir = /data/graylog-server
message_journal_dir = /data/graylog-server/journal

再次查看是否有报错。

服务最后重启时间，持续跟进服务状态。

Thu Aug 1 20:18:58 CST 2024

问题解决验证

脚本并发500qps，研发查看graylog是否存在丢失日志情况，查看各个IP地址编制表格，web展示数据最终查的2306682条，服务器日志wc统计数据最终查的2306682条。

至此任务完成。

总结服务配置

graylog服务配置

总结graylog优化 主配置文件 /etc/graylog/server/server.conf

is_leader = true
node_id_file = /etc/graylog/server/node-id
password_secret = 7QK-x6klxxxxxxxxxnnoj0xxxxxxxxxxxxxxxxD1W1s8WCkU0ZVDxrj6c1S7fu
root_password_sha2 = d5d62ec09cb20fxxxxxxxxxxxxxxxxxxx8739fxxxxxxdb
root_timezone = Asia/Shanghai
bin_dir = /usr/share/graylog-server/bin
# graylog服务临时存储目录
data_dir = /data/graylog-server
plugin_dir = /usr/share/graylog-server/plugin
# graylog服务
http_bind_address = graylog-server:9000
stream_aware_field_types=false
elasticsearch_hosts = http://es-server:9200
# 最大保存日志天数
max_index_retention_period = P180d
# 设置为false表示不允许在查询字符串的开头使用通配符。
allow_leading_wildcard_searches = false
# 设置为false表示关闭搜索结果中的关键词高亮功能。
allow_highlighting = false
# 设置为15000表示每次向输出插件发送15000条日志数据。
output_batch_size = 15000
# 设置为5秒表示如果没有新的日志数据到来，每5秒强制刷新一次输出。
output_flush_interval = 5
# 设置为20表示如果输出插件连续失败20次，则触发故障处罚。
output_fault_count_threshold = 20
# 设置为120秒表示如果达到故障阈值，则暂停输出插件120秒。
output_fault_penalty_seconds = 120


# 设置为30表示处理缓冲区中有30个线程负责处理日志数据。
processbuffer_processors = 30
# 设置为30表示输出缓冲区中有30个线程负责处理日志数据。
outputbuffer_processors = 30
# 设置为sleeping表示线程在等待时会进入睡眠状态。
processor_wait_strategy = sleeping
# 设置为16777216字节（约16MB）表示环形缓冲区的大小。
ring_size = 16777216
# 设置为16777216字节（约16MB）表示输入缓冲区的环形缓冲区大小。
inputbuffer_ring_size = 16777216
# 设置为30表示输入缓冲区中有30个线程负责处理日志数据。
inputbuffer_processors = 30
# 设置为sleeping表示线程在等待时会进入睡眠状态。
inputbuffer_wait_strategy = sleeping
# 设置为true表示启用消息日志功能，有助于在系统崩溃时恢复未处理的消息。
message_journal_enabled = true
# 设置为/data/graylog-server/journal表示消息日志将存储在这个目录下。
message_journal_dir = /data/graylog-server/journal
# 设置为3秒表示负载均衡器每隔3秒检查是否有新的节点加入集群。
lb_recognition_period_seconds = 3

# mogodb配置
mongodb_uri = mongodb://localhost/graylog
mongodb_max_connections = 1500

# 邮件配置
transport_email_enabled = true
transport_email_hostname = smtp.qiye.aliyun.com
transport_email_port = 465
transport_email_use_auth = true
transport_email_auth_username = graylog@xxxxxx.com
transport_email_auth_password = xxxxxx
transport_email_from_email = graylog@xxxxxx.com
transport_email_socket_connection_timeout = 10s
transport_email_socket_timeout = 10s
transport_email_use_tls = false
transport_email_use_ssl = true

# 设置为189582500字节（约180MB）表示接收缓冲区的大小。
input_beats_receive_buffer_size = 189582500
# 设置为524288000字节（约500MB）表示消息日志文件的最大大小。
journal_max_file_size_bytes=524288000
# 设置为7天表示消息日志文件将保留7天。
message_journal_retention_time=7d
# 设置为disk表示输入缓冲区使用磁盘存储。
input_buffer_type=disk
# 设置为10000表示输入缓冲区可以容纳10000条消息。
input_buffer_size=10000
# 设置为async表示消息日志采用异步持久化策略。
message_journal_persistence_strategy=async
# 设置为32768表示环形缓冲区可以容纳32768条消息。
ring_buffer_size = 32768
# 设置为50000毫秒（即50秒）表示流路由器处理消息的最大等待时间为50秒。
stream_router_timeout = 50000

配置文件 /etc/sysconfig/graylog-server （根据硬件配置）

# Path to a custom java executable. By default the java executable of the
# bundled JVM is used.
#JAVA=/usr/bin/java

# Default Java options for heap and garbage collection.
GRAYLOG_SERVER_JAVA_OPTS="-Xms120g -Xmx130g -server -XX:+UseG1GC"


# Avoid endless loop with some TLSv1.3 implementations.
GRAYLOG_SERVER_JAVA_OPTS="$GRAYLOG_SERVER_JAVA_OPTS -Djdk.tls.acknowledgeCloseNotify=true"

# Fix for log4j CVE-2021-44228
GRAYLOG_SERVER_JAVA_OPTS="$GRAYLOG_SERVER_JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"

# Pass some extra args to graylog-server. (i.e. "-d" to enable debug mode)
GRAYLOG_SERVER_ARGS=""

# Program that will be used to wrap the graylog-server command. Useful to
# support programs like authbind.
GRAYLOG_COMMAND_WRAPPER=""

elasticsearch服务配置

grep -v '#' /etc/elasticsearch/elasticsearch.yml
path.data: /data/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
cluster.initial_master_nodes: ["elasticsearch-server"]
http.max_content_length: 1000mb

jvm.options

-Xms40g
-Xmx40g

filebeat服务配置

这里只展示output配置文件部分

output.logstash:
  hosts: ["graylog-server:5044"]
  workers: 4 # 增加并发工作线程数
  queue:
    events: 2000 # 增加队列中事件的数量
    length: 200 # 增加队列中批次的数量
  retry:
    on_failure: true
    backoff: 5s # 设置失败后的重试间隔
    max: 5 # 设置最大重试次数

系统配置

/etc/security/limits.conf

* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576

/etc/sysctl.conf

net.core.rmem_default = 36214400


net.ipv4.tcp_max_tw_buckets = 1048576
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_retries2 = 10
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_mem = 8388608 12582912 16777216
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 8192 65535 16777216
# 定义了系统中每一个端口监听队列的最大长度
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_abort_on_overflow = 1
# # 增大每个套接字的缓冲区大小
net.core.optmem_max = 81920
# # 增大套接字接收缓冲区大小
net.core.rmem_max = 16777216
# # 增大套接字发送缓冲区大小
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 65535