Graylog日志丢失解决方案

news2024/11/17 17:37:55

问题描述

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

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2075949.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

盘点15款主流的项目管理软件，优缺点一目了然！

盘点15款主流的项目管理软件，优缺点一目了然！

本文将盘点对15款主流的项目管理软件进行盘点&#xff1a; 简道云、Worktile、Teambition、Tower、泛微 e-office、用友项目管理软件、金蝶云星瀚项目管理、腾讯 TAPD、Asana、Trello、Jira、Basecamp、Monday.com、Wrike、Smartsheet。 在现代企业的运营中&#xff0c;项目管理…
阅读更多...
uniapp，uview：inputnumber或者input，当type为number的时候，在ios里输入不了小数的问题

uniapp，uview：inputnumber或者input，当type为number的时候，在ios里输入不了小数的问题

项目场景&#xff1a; 在做uniapp的H5页面时&#xff0c;有个需求是要输入框要能支持可以保留两位小数输入&#xff0c;不能输入负数和其他字符。心想这简单&#xff0c;直接用uview的inputnumber组件这不就好了&#xff0c;结果测试提bug说不能输入小数点&#xff0c;我心想我…
阅读更多...
基于Hadoop+Zookeeper+Hive+HBase+Echarts的地区旅游大数据可视化管理系统设计与实现

基于Hadoop+Zookeeper+Hive+HBase+Echarts的地区旅游大数据可视化管理系统设计与实现

绪论 研究背景 当今时代信息资源日益丰富大量&#xff0c;信息资源的利用对社会的发展起着主要作用&#xff0c;运用信息技术协助产业设计越来越成为行业发展的重要趋势。 旅游产业是典型的体验服务产业&#xff0c;在任何发展阶段&#xff0c;信息反馈的准确性与及时性都具…
阅读更多...
【表格】EEG作为脑成像工具的分析与应用

【表格】EEG作为脑成像工具的分析与应用

EEG作为脑成像工具的分析与应用 【表格】EEG空间分析方法与应用 方法/应用描述关键点示例/公式备注全局场功率(GFP)量化头皮电位场的强度 G F P σ ( V t ) GFP \sigma(V_t) GFPσ(Vt​) 其中 V t V_t Vt​为t时刻各电极电压无具体公式&#xff0c;为标准差计算提供对同步活…
阅读更多...
C和C++中数组的不同

C和C++中数组的不同

本文选自公众号文章&#xff1a; https://mp.weixin.qq.com/s/xyUMWTyEu7-Uws8Zfxifpghttps://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxcheckurl?requrlhttps%3A%2F%2Fmp.weixin.qq.com%2Fs%2FxyUMWTyEu7-Uws8Zfxifpg&skey%40crypt_963c540a_c8e6882f00ef27f0c27a8357dea50…
阅读更多...
了解Redis数据持久化（下）

了解Redis数据持久化（下）

4.AOF 写后日志&#xff0c;避免宕机数据丢失 4.1 AOF说明 AOF日志存储的是Redis服务器的顺序指令序列只记录对内存进行修改的指令append-only file&#xff08;AOF&#xff09;AOF主要是主线程在执行&#xff0c;将日志写入磁盘的过程中&#xff0c;如果磁盘压力太大&#x…
阅读更多...
USB3.2 摘录（九）

USB3.2 摘录（九）

系列文章目录 USB3.2 摘录&#xff08;一&#xff09; USB3.2 摘录&#xff08;二&#xff09; USB3.2 摘录&#xff08;三&#xff09; USB3.2 摘录&#xff08;四&#xff09; USB3.2 摘录&#xff08;五&#xff09; USB3.2 摘录&#xff08;六&#xff09; USB3.2 摘录&…
阅读更多...
HCIA--网络地址转换NAT技术

HCIA--网络地址转换NAT技术

NAT(Network Address Translation&#xff0c;网络地址转换技术是为了缓解IPv4地址有限的问题。 NAT技术主要用于实现内部网络的主机访问外部网络。一方面NAT缓解了IPv4地址短缺的问题&#xff0c;另一方面NAT技术让外网无法直接与使用私有地址的内网进行通信&#xff0c;提升…
阅读更多...
【ACL2024教程】大型语言模型对抗攻击的脆弱性，200多页ppt

【ACL2024教程】大型语言模型对抗攻击的脆弱性，200多页ppt

本教程全面概述了大型语言模型&#xff08;LLMs&#xff09;在对抗攻击下暴露的脆弱性——这是一个可信机器学习中新兴的跨学科领域&#xff0c;结合了自然语言处理&#xff08;NLP&#xff09;和网络安全的视角。我们强调了单模态LLM、多模态LLM以及集成LLM的系统中现有的脆弱…
阅读更多...
FPGA上板项目（三）——RAM测试

FPGA上板项目（三）——RAM测试

目录 实验内容实验原理实验步骤实验用时序波形HDL 代码仿真综合实现上板测试 实验内容 对 FPGA 内部的 RAM 进行数据读写操作。 实验原理 RAM &#xff08;Random Access Memory&#xff09;&#xff0c;是可以进行数据交换的存储器&#xff0c;可读可写&#xff1b;而 ROM&…
阅读更多...
Docker一行命令安装MySQL

Docker一行命令安装MySQL

1 前言 在Linux系统中安装MySQL数据库是一件繁琐的事情&#xff0c;经常遇到各种问题&#xff0c;浪费大量时间。Docker的出现很好的解决这个问题&#xff0c;下面然我们来学习如何在Docker中用一行命令安装MySQL。 2 安装Docker 这里以CentOS系统为例&#xff0c;步骤非常简…
阅读更多...
这4款专业的思维导图工具教你怎么快速制作脑图。

这4款专业的思维导图工具教你怎么快速制作脑图。

思维导图怎么制作&#xff1f;其实很简单&#xff0c;在制作思维导图之前&#xff0c;先要明确自己的导图主体&#xff0c;然后就可以去选择一个合适的工具&#xff0c;就可以开始制作。如果不知道如何挑选工具的话&#xff0c;我可以帮助大家列举几个。 1、福昕365脑图 传送门…
阅读更多...
关于前端布局的基础知识

关于前端布局的基础知识

float 横向布局 float 实现横向布局&#xff0c;需要向横着布局的元素添加float 其值left right 存在问题 如果使用float 所在父级五高度&#xff0c;会导致下方的元素上移 top的高度被吞了 解决方法&#xff1a; 给父级元素设置高度&#xff1a;不推荐&#xff0c;需要给父级…
阅读更多...
盘点15款主流客户管理系统，助力企业选型！

盘点15款主流客户管理系统，助力企业选型！

本文将盘点15款主流客户管理系统&#xff1a; 简道云、纷享销客、销售易、HubSpot、Zoho CRM、SAP CRM、Oracle CRM、金蝶云星空 CRM、用友 CRM、悟空 CRM、Salesforce、Microsoft Dynamics 365、亿客 CRM、八百客 CRM、CloudCC CRM。 在当今的商业环境中&#xff0c;客户管理系…
阅读更多...
能大致讲一下Chat GPT的原理吗？

能大致讲一下Chat GPT的原理吗？

AI视频生成&#xff1a;小说文案智能分镜智能识别角色和场景批量Ai绘图自动配音添加音乐一键合成视频百万播放量https://aitools.jurilu.com/ 话题群精选了三位网友的回答&#xff0c;从不同的角度阐释了Chat GPT的原理。 第一位网友的回答&#xff1a; 不给你扯长篇大论&#…
阅读更多...
SpringBoot整合MyBatis使用自定义TypeHandler

SpringBoot整合MyBatis使用自定义TypeHandler

&#x1f604; 19年之后由于某些原因断更了三年&#xff0c;23年重新扬帆起航&#xff0c;推出更多优质博文&#xff0c;希望大家多多支持&#xff5e; &#x1f337; 古之立大事者&#xff0c;不惟有超世之才&#xff0c;亦必有坚忍不拔之志 &#x1f390; 个人CSND主页——Mi…
阅读更多...
系统知识小百科：如何禁用电脑无关软件！

系统知识小百科：如何禁用电脑无关软件！

禁用电脑上的无关软件是提升系统性能和安全性的有效手段。 以下是一些主要的方法来帮助你禁用这些软件&#xff1a; 一、通过Windows系统设置卸载无用软件 打开设置&#xff1a;按下Win I打开Windows设置。 进入应用管理&#xff1a;点击“应用”选项&#xff0c;这里会列出…
阅读更多...
2024最新盘点！哪些仓库管理系统值得推荐？

2024最新盘点！哪些仓库管理系统值得推荐？

本文将对16款仓库管理系统进行盘点&#xff1a; 简道云仓库管理系统、Oracle Warehouse Management、富勒、音飞储存、Microsoft Dynamics 365、金蝶、Logiwa、易订货、Fishbowl Warehouse、百卓轻云、智慧记、Oracle NetSuite、鸿链科技 WMS 仓库管理系统、Infor CloudSuite、…
阅读更多...
武汉流星汇聚：亚马逊赋能中小企业，跨境电商市场举足轻重地位稳

武汉流星汇聚：亚马逊赋能中小企业，跨境电商市场举足轻重地位稳

在全球经济一体化的浪潮中&#xff0c;跨境电商作为推动国际贸易的重要力量&#xff0c;正以前所未有的速度发展。在这场全球性的商业竞赛中&#xff0c;亚马逊以其卓越的市场表现、强大的技术实力和深厚的品牌影响力&#xff0c;稳居跨境电商市场的领头羊地位&#xff0c;其举…
阅读更多...
视频美颜SDK与直播美颜插件的开发指南：从基础到高级应用

视频美颜SDK与直播美颜插件的开发指南：从基础到高级应用

今天&#xff0c;笔者将详细讲解如何从基础到高级应用开发视频美颜SDK与直播美颜插件。 一、视频美颜SDK的基础概念与架构设计 视频美颜SDK是一种集成在移动应用或桌面应用中的软件开发工具包&#xff0c;允许开发者在视频流中实现实时美颜效果。其核心功能包括肤色调整、磨皮…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023