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 timeclass WriterThread(threading.Thread):def __init__(self, queue):threading.Thread.__init__(self)self.queue = queuedef run(self):while True:line = self.queue.get()if line is None:breaklock.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_timeif 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: truebackoff: 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 closedat 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 spaceat 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 spaceat 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 spaceat 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 closedat 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: truebackoff: 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 = 36214400net.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.rhkb.cn/news/410293.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

[论文阅读] mobile aloha实验部分

[论文阅读] mobile aloha实验部分

DP:[1] CHI C, FENG S, DU Y, et al. Diffusion Policy: Visuomotor Policy Learning via Action Diffusion[J]. 2023. Diffusion Policy: Visuomotor Policy Learning via Action Diffusion精读笔记&#xff08;一&#xff09;-CSDN博客 哥伦比亚大学突破性的方法- Diffusio…
阅读更多...
Android中apk安装过程源码解析

Android中apk安装过程源码解析

本文中使用的Android源码基于Android 14 1 三方应用安装apk调用方法 public void installApk() {Intent intent new Intent(Intent.ACTION_VIEW);intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);/** 自Android N开始&#xff0c;是通过FileProvider共享相关文件&#xff0…
阅读更多...
git提交本地项目到远程仓库

git提交本地项目到远程仓库

1、查看项目目录&#xff0c;是否存在.git文件夹&#xff08;若存在则删除&#xff09; 2、登录git并新建一个空白项目 3、idea创建本地git仓库&#xff08;选择本地项目&#xff09; 4、添加要提交的项目&#xff08;项目右键&#xff09; 5、提交代码到本地仓库 6、配置远程…
阅读更多...
SQLserver中的游标的分类和游标的生命周期

SQLserver中的游标的分类和游标的生命周期

SQLserver中的游标的分类 在 SQL Server 中&#xff0c;游标&#xff08;Cursor&#xff09;是一种数据库对象&#xff0c;用于逐行处理结果集中的数据。游标可以用于复杂的数据处理任务&#xff0c;尤其是那些不能通过简单的 SELECT 语句和 JOIN 操作完成的任务。SQL Server …
阅读更多...
48.x86游戏实战-封包抓取进图call

48.x86游戏实战-封包抓取进图call

免责声明&#xff1a;内容仅供学习参考&#xff0c;请合法利用知识&#xff0c;禁止进行违法犯罪活动&#xff01; 本次游戏没法给 内容参考于&#xff1a;微尘网络安全 工具下载&#xff1a; 链接&#xff1a;https://pan.baidu.com/s/1rEEJnt85npn7N38Ai0_F2Q?pwd6tw3 提…
阅读更多...
OpenAI API: How to count tokens before API request

OpenAI API: How to count tokens before API request

题意&#xff1a;“OpenAI API&#xff1a;如何在 API 请求之前计算令牌数量” 问题背景&#xff1a; I would like to count the tokens of my OpenAI API request in R before sending it (version gpt-3.5-turbo). Since the OpenAI API has rate limits, this seems impor…
阅读更多...
OpenLayers3,地图探查功能实现

OpenLayers3,地图探查功能实现

文章目录 一、前言二、代码实现三、总结 一、前言 图层探查&#xff0c;即对置于地图下方的图层进行一定范围的探查&#xff0c;以便用户查看到不易察觉的地理地况。本文基于OpenLayers3&#xff0c;实现地图探查的功能。 二、代码实现 <!DOCTYPE HTML PUBLIC "-//W…
阅读更多...
基于Transformer架构的大模型推理硬件加速器设计

基于Transformer架构的大模型推理硬件加速器设计

概述 当前大模型的基础架构正在向 Transformer 结构收敛1&#xff0c;Transformer架构自谷歌2017年提出后比较稳定&#xff0c;因此针对Transformer的计算设计专用的ASIC加速器很有必要。 尤其是“Attention is All you Need”》“Money is All you Need”&#xff0c;哈哈哈…
阅读更多...
MySQL的源码安装及基本部署(基于RHEL7.9)

MySQL的源码安装及基本部署(基于RHEL7.9)

这里源码安装mysql的5.7.44版本 一、源码安装 1.下载并解压mysql , 进入目录: wget https://downloads.mysql.com/archives/get/p/23/file/mysql-boost-5.7.44.tar.gz tar xf mysql-boost-5.7.44.tar.gz cd mysql-5.7.44/ 2.准备好mysql编译安装依赖: yum install cmake g…
阅读更多...
使用vueuse在组件内复用模板

使用vueuse在组件内复用模板

1. 安装vueusae pnpm i vueuse/core2. 组件内复用模板 createReusableTemplate 是vueuse中的一个实用工具&#xff0c;用于在 Vue 3 中创建可重复使用的模板片段&#xff0c;同时保持状态的独立性。这对于需要在多个组件中重复使用相同的结构和逻辑时非常有用。 因为这些可复…
阅读更多...
链表OJ题——使用栈实现单链表的逆序打印

链表OJ题——使用栈实现单链表的逆序打印

文章目录 一、题目链接二、解题思路三、解题代码 一、题目链接 题目描述&#xff1a;使用栈&#xff0c;实现单链表的逆序打印 二、解题思路 三、解题代码 /*** 非递归实现单链表的顶逆序打印——>通过栈来实现* param*/public void printReverseListFromStack(){Stack<…
阅读更多...
短视频SDK解决方案，原开发团队，一对一技术支持

短视频SDK解决方案，原开发团队，一对一技术支持

美摄科技&#xff0c;作为行业领先的视频技术提供商&#xff0c;凭借深厚的技术积累和敏锐的市场洞察&#xff0c;隆重推出其短视频SDK解决方案&#xff0c;旨在为全球开发者及内容创作者搭建一座通往无限创意与高效生产的桥梁。 【一站式解决方案&#xff0c;赋能创意无界】 …
阅读更多...
【js原型和原型链】

【js原型和原型链】

js原型和原型链 一、构造函数和原型对象中的this二、原型对象的constructor属性三、原型链四、关系图五、普通函数和函数对象 参考文章链接: link 一、构造函数和原型对象中的this 指向实例对象 // 定义构造函数function Star(name,age){this.name name;this.age age;conso…
阅读更多...
前端面试题 webpack的工作流程

前端面试题 webpack的工作流程

一、流程图 二、重要概念 1.entry入口&#xff1a; Webpack 从配置的入口点开始&#xff0c;分析应用程序的依赖关系 2.output出口&#xff1a; 定义了打包后的文件如何输出&#xff0c;包括文件名和输出路径。 3.loader加载器&#xff1a; Webpack 本身只能处理 JavaScr…
阅读更多...
Bytebase 2.22.2 - 允许在工作空间为群组分配角色

Bytebase 2.22.2 - 允许在工作空间为群组分配角色

&#x1f680; 新功能 允许在工作空间给群组分配角色。 支持禁用邮箱密码登录&#xff0c;仅允许 SSO 登录的设置项。 新增 Postgres SQL 审核规则&#xff1a;禁止在列上设置会变化的默认值。 &#x1f514; 重大变更 下线项目内的变更历史页面&#xff1b;所有变更历史仍可…
阅读更多...
uboot环境变量擦除之烧录工具擦除flash mtd0分区

uboot环境变量擦除之烧录工具擦除flash mtd0分区

有时会uboot环境变量修改了没有生效,需要擦除整个mtd分区 Erasing at 0x100000 – 100% complete. &#xff08;1M&#xff09; uboot给flash的中分区
阅读更多...
实体书商城小程序的设计

实体书商城小程序的设计

管理员账户功能包括&#xff1a;系统首页&#xff0c;个人中心&#xff0c;用户管理&#xff0c;小说分类管理&#xff0c;小说信息管理&#xff0c;订单管理&#xff0c;系统管理 微信端账号功能包括&#xff1a;系统首页&#xff0c;小说信息&#xff0c;小说资讯&#xff0…
阅读更多...
IGE-LIO：充分利用强度信息克服激光退化场景下的定位精度

IGE-LIO：充分利用强度信息克服激光退化场景下的定位精度

更多优质内容&#xff0c;请关注公众号&#xff1a;智驾机器人技术前线 1.论文信息 论文标题&#xff1a;IGE-LIO: Intensity Gradient Enhanced Tightly-Coupled LiDAR-Inertial Odometry 作者&#xff1a;Ziyu Chen, Hui Zhu, Biao Yu, Chunmao Jiang, Chen Hua, Xuhui Fu a…
阅读更多...
图新说-调整标绘线面的压盖顺序的两种方法

图新说-调整标绘线面的压盖顺序的两种方法

0.序 图新说作为一个三维可视化汇报工具&#xff0c;在公安消防领域常用于做态势标绘&#xff0c;应急救援方案&#xff0c;安保预案等。 如果撤离路线&#xff0c;或者行进路线【线对象】经过了水源地、危险区等【面对象】。如何确保线对象显示在面对象的上面&#xff0c;不被…
阅读更多...
Nginx的核心！！！ 负载均衡、反向代理

Nginx的核心！！！ 负载均衡、反向代理

目录 负载均衡 1.轮询 2.最少连接数 3.IP哈希 4.加权轮询 5.最少时间 6.一致性哈希 反向代理 测试 之前讲过Nginx 的简介和正则表达式&#xff0c;那些都是Nginx较为基础的操作&#xff0c;Nginx 最重要的最核心的功能&#xff0c;当属反向代理和负载均衡了。 负载均…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023