Graylog日志丢失解决方案

运维潇哥2024-08-27 23:10

问题描述

目前公司使用的日志方案是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编写即可。

python 复制代码 
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配置 代码如下：

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

bash 复制代码 
output.logstash:
  hosts: ["graylog-server:5044"]

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

bash 复制代码 
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服务的内存硬件资源

bash 复制代码 
cat jvm.options 
## JVM configuration

-Xms8g
-Xmx10g

增加消息重试机制。

bash 复制代码 
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配置参数 等，增加内存参数

bash 复制代码 
#  /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 选项来增大接收缓冲区大小。重启服务

bash 复制代码 
beats_input_socket_receive_buffer_size=209715200  # 设置为 200MB

问题七

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

bash 复制代码 
​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

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

增加配置文件 重启服务

bash 复制代码 
eats_input_idle_timeout=60s  # 增加空闲超时时间

问题八

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

bash 复制代码 
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的内存配置，重启服务。

bash 复制代码 
GRAYLOG_SERVER_JAVA_OPTS="-Xms60g -Xmx80g -server -XX:+UseG1GC"

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

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

问题九

新的问题报错描述：

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

服务器日志端：报错日志

bash 复制代码 
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

bash 复制代码 
# 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异常高。

bash 复制代码 
尝试解决中：

变更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 服务依然挂了，上面方法未能生效。

报错日志如下：

bash 复制代码 
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、调整消息队列的大小限制来减少内存使用

bash 复制代码 
journal_max_file_size_bytes=104857600 # 100 MB
journal_max_total_size_bytes=524288000 # 500 MB

2、增加内存

bash 复制代码 
GRAYLOG_SERVER_JAVA_OPTS="-Xms70g -Xmx80g -server -XX:+UseG1GC"

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

问题十

日志信息：

bash 复制代码 
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 来不及消费了。

原有配置

bash 复制代码 
connect_timeout: 1000
hostname: graylog-server
max_inflight_sends: 512
port: 12201
protocol: UDP
queue_size: 512
reconnect_delay: 500

变更配置

bash 复制代码 
connect_timeout: 1000000
hostname: graylog-server
max_inflight_sends: 5120000
port: 12201
protocol: UDP
queue_size: 5120000
reconnect_delay: 500000

以上配置未能解决问题

增加graylog配置文件

bash 复制代码 
message_journal_retention_time=7d
input_buffer_type=disk
input_buffer_size=10000
#indices_number_of_replicas=1
message_journal_persistence_strategy=async

问题十一

graylog卡顿报错日志

bash 复制代码 
​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服务会把接受到的消息，无法及时处理的消息，先存储到这个目录里）

bash 复制代码 
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

bash 复制代码 
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 （根据硬件配置）

bash 复制代码 
# 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服务配置

bash 复制代码 
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

bash 复制代码 
-Xms40g
-Xmx40g

filebeat服务配置

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

bash 复制代码 
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

bash 复制代码 
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576

/etc/sysctl.conf

bash 复制代码 
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
相关推荐
mubeibeinv18 分钟前
项目搭建+图片(添加+图片)
java·服务器·前端
dessler22 分钟前
Docker-如何启动docker
运维·docker·云原生·容器·eureka
zhy2956322 分钟前
【DOCKER】基于DOCKER的服务之DUFS
运维·docker·容器·dufs
秋名山小桃子37 分钟前
Kunlun 2280服务器(ARM)Raid卡磁盘盘符漂移问题解决
运维·服务器
与君共勉1213838 分钟前
Nginx 负载均衡的实现
运维·服务器·nginx·负载均衡
努力学习的小廉1 小时前
深入了解Linux —— make和makefile自动化构建工具
linux·服务器·自动化
MZWeiei1 小时前
Zookeeper基本命令解析
大数据·linux·运维·服务器·zookeeper
Arenaschi1 小时前
在Tomcat中部署应用时，如何通过域名访问而不加端口号
运维·服务器
小张认为的测试1 小时前
Linux性能监控命令_nmon 安装与使用以及生成分析Excel图表
linux·服务器·测试工具·自动化·php·excel·压力测试
waicsdn_haha1 小时前
Java/JDK下载、安装及环境配置超详细教程【Windows10、macOS和Linux图文详解】
java·运维·服务器·开发语言·windows·后端·jdk
热门推荐
01〔AI 绘画〕Stable Diffusion 之 解决绘制多人或面部很小的人物时面部崩坏问题 篇02ARM学习（31）编译器对overlay方式的支持03玄机平台应急响应—webshell查杀04解决java读取EXCEL数据变成科学计数法的问题05校验 GPT-4 真实性的三个经典问题：快速区分 GPT-3.5 与 GPT-4，并提供免费测试网站06Docker 夺命连环 15 问07DisplayPort AltMode On Type-c协议_Ver2.0(学习笔记)08基于大语言模型（LLM）的合成数据生成、策展和评估的综述09(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明106个主流的工业3D管道设计软件