登录
  • 欢迎访问悠扬的技术博客,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站😉

分库分表组件线程性能优化相关记录点

Mysql 悠扬 367次浏览 已收录 0个评论

分库分表组件线程性能优化相关记录点

Logstash

   1.配置文件控制任务数

vim /etc/logstash/logstash.yml

pipeline.workers: 24

pipeline.batch.size: 10000

pipeline.batch.delay: 10

Logstash建议在修改配置项以提高性能的时候,每次只修改一个配置项并观察其性能和资源消耗(cpu、io、内存)。性能检查项包括:

1、检查input和output设备
1)、CPU
2)、Memory
3)、io
2、磁盘io
3、网络io
4、检查jvm堆
5、检查工作线程设置

2.配置说明

Logstash持久化到磁盘,当发生异常情况,比如logstash重启,有可能发生数据丢失,可以选择logstash持久化到磁盘,修改之前重启logstash数据丢失,修改之后重启logstash数据不丢失。
以下是具体操作:

queue.type: persisted
path.queue: /usr/share/logstash/data #队列存储路径;如果队列类型为persisted,则生效
queue.page_capacity: 250mb #队列为持久化,单个队列大小
queue.max_events: 0 #当启用持久化队列时,队列中未读事件的最大数量,0为不限制
queue.max_bytes: 1024mb #队列最大容量
queue.checkpoint.acks: 1024 #在启用持久队列时强制执行检查点的最大数量,0为不限制
queue.checkpoint.writes: 1024 #在启用持久队列时强制执行检查点之前的最大数量的写入事件,0为不限制
queue.checkpoint.interval: 1000 #当启用持久队列时,在头页面上强制一个检查点的时间间隔

优化input,filter,output的线程模型。

增大 filter和output worker 数量 通过启动参数配置 -w 48 (等于cpu核数),logstash正则解析极其消耗计算资源,而我们的业务要求大量的正则解析,因此filter是我们的瓶颈。
官方建议线程数设置大于核数,因为存在I/O等待。
增大 woker 的 batch_size 150 -> 3000 通过启动参数配置 -b 3000

内存

logstash是将输入存储在内存之中,worker数量 * batch_size = n * heap (n 代表正比例系数)


Logstash的优化相关配置

默认配置 —> pipeline.output.workers: 1官方建议是等于 CPU 内核数

可优化为 —> pipeline.output.workers: 不超过pipeline 线程数

默认配置 —> pipeline.workers:** 2
      可优化为 —> pipeline.workers: CPU 内核数(或几倍 cpu 内核数)**

实际 output 时的线程数

默认配置 —> pipeline.output.workers: 1
可优化为 —> pipeline.output.workers: 不超过 pipeline 线程数

每次发送的事件数

默认配置 ---> pipeline.batch.size: 125 
可优化为 ---> pipeline.batch.size: 1000

发送延时

默认配置 ---> pipeline.batch.delay: 5
可优化为 ---> pipeline.batch.size: 10

参考建议

# pipeline线程数,官方建议是等于CPU内核数
pipeline.workers: 24
# 实际output时的线程数
pipeline.output.workers: 24
# 每次发送的事件数
pipeline.batch.size: 3000
# 发送延时
pipeline.batch.delay: 5

注意:当batch.size增大,es处理的事件数就会变少,写入也就越快了。此问题用以下办法解决
就是你的bulk线程池处理不过来你的请求。处理方案:调整你es集群的bulk队列大小(默认为50),或增加你的es内存

解决办法 :
官方的建议是提高每次批处理的数量,调节传输间歇时间。当batch.size增大,es处理的事件数就会变少,写入也就愉快了。
具体的worker/output.workers数量建议等于CPU数,batch.size/batch.delay根据实际的数据量逐渐增大来测试最优值。

总结
通过设置 -w 参数指定 pipeline worker 数量,也可直接修改配置文件 logstash.yml。这会提高 filter 和 output 的线程数,如果需要的话,将其设置为 cpu 核心数的几倍是安全的,线程在 I/O 上是空闲的。
默认每个输出在一个 pipeline worker 线程上活动,可以在输出 output 中设置 workers 设置,不要将该值设置大于
pipeline worker 数。
还可以设置输出的 batch_size 数,例如 ES 输出与 batch size 一致。
filter 设置 multiline 后,pipline worker 会自动将为 1,如果使用 filebeat,建议在 beat中就使用 multiline,如果使用 logstash 作为 shipper,建议在 input 中设置 multiline,不要在filter 中设置 multiline
还有请注意插件连接池的数量设置,比如mysql最大连接数,单个脚本文件中的配置设置

logstash-jdbc-output插件

链接池偶尔报错:HikariPool-1 – Connection is not available, request timed out after 39985ms.

记录:调试相关插件配置,最终发现是因为logstash work数过大,CPU配置,任务配置文件中关于线程,连接池配置不合理导致

Sharding-proxy

点击查看proxys属性配置 

主要是修改连接池,一个是proxy自己的连接池,一个是每个分片库配置使用的最大连接池,别太大,理解以下CPU抢占,线程搞太多反而影响效率,也不能太小,太小吞吐量太差

 


版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明分库分表组件线程性能优化相关记录点
喜欢 (0)
支付宝[]
分享 (0)
悠扬
关于作者:
10年以上工作经验,从事2年微服务架构搭建工作,有大数据处理相关工作经验,使用spring全家桶包括:Spring,SpringBoot,SpringCloud 数据层组件服务使用SpringDataJpa,Mybatis以及其他第三方组件Sharding-JDBC,Sharding-Proxy分库分表。熟悉微服务,服务降级,限流,分流,做过项目源码修改,有cat,apollo,nacos使用经验,有Lostash,Elasticsearch,kibana,mysqlMHA生产实践经验,使用开源代码Apache Sarding项目,修改源码支持mysql分库分表使用年月日小时分库分表,docker做集群服务,Jekins做项目发布,GitLab做项目管理,使用docker容器部署,熟悉消息队列RabbitMQ,Kafka,ActiveMQ。RuoYi-Vue-Atomikos项目开源加入生态圈组件,项目支持分布式事务,界面添加多数据源,数据源动态配置,切面切换,多数据源事务支持,支持区域数据源配置,用于区域数据切分,数据层次分库。项目地址:https://gitee.com/zsiyang/ruoyi-vue-atomikos
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址