来自于:https://blog.csdn.net/youaremoon/article/details/51884644 感谢博主,收藏一下 dubbo作为一个服务治理框架,功能相对比较完善,性能也挺不错.但很多朋友在使用dubbo的时候,只是简单的参考官方说明进行搭建,并没有过多的去思考一些关键参数的意义(也可能是时间紧任务多,没空出来研究),最终做出来的效果有一定的打折. 这里我根据目前我们项目的使用情况列出几个性能调优的参数及其意义,供大家参考. 在介绍参数之前,我们先了解下dubbo中

前言 micrometer中自带了很多其他框架的指标信息,可以很方便的通过prometheus进行采集和监控,常用的有JVM的信息,Http请求的信息,Tomcat线程的信息等. 对于一些比较活跃的框架,有些还是不支持的,比如Dubbo.如果想监控Dubbo的一些指标,比如线程池的状况,我们需要手动去扩展,输出对应的线程池指标才行. 在这种情况下,肯定是没什么思路的,因为你不知道怎么去扩展,下面给大家介绍去做一件事情之前的思考,方式方法很重要. Dubbo有没有现成的实现? 参考micromet

DynamicTp 简介 DynamicTp 是一个基于配置中心实现的轻量级动态线程池管理工具,主要功能可以总结为 动态调参.通知报警.运行监控.三方包线程池管理等几大类. 经过几个版本迭代,目前最新版本v1.0.6具有以下特性 特性 代码零侵入:所有配置都放在配置中心,对业务代码零侵入 轻量简单:基于 springboot 实现,引入 starter,接入只需简单4步就可完成,顺利3分钟搞定 高可扩展:框架核心功能都提供 SPI 接口供用户自定义个性化实现(配置中心.配置文件解析.通知告警.监

前言:最近项目中与融360项目中接口对接,有反馈接口(也就是我们接收到请求,需要立即响应,并且还要有一个接口推送给他们其他计算结果),推送过程耗时.或者说两个接口不能是同时返回,有先后顺序. 这时我想到了把自己Controller立即返回接受成功,中间添加一个新的线程去做其他耗时的操作(线程池配置和参数测试讲解请阅读第5步). 1.Controller代码如下: @Autowiredprivate CallThreadDemo worker; @RequestMapping("/bandBank

Spring线程池ThreadPoolTaskExecutor配置及详情 1. ThreadPoolTaskExecutor配置 <!-- spring thread pool executor --> <bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor"> <!-- 线程池维护线程的最少数量 --

1.ThreadPoolExecutor的重要参数 1.corePoolSize:核心线程数 * 核心线程会一直存活,及时没有任务需要执行 * 当线程数小于核心线程数时,即使有线程空闲,线程池也会优先创建新线程处理 * 设置allowCoreThreadTimeout=true(默认false)时,核心线程会超时关闭 2.queueCapacity:任务队列容量(阻塞队列) * 当核心线程数达到最大时,新任务会放在队列中排队等待执行 3.maxPoolSize:最大线程数 * 当线程数>=cor

上一篇我们介绍了如何使用@Async注解来创建异步任务,我可以用这种方法来实现一些并发操作,以加速任务的执行效率.但是,如果只是如前文那样直接简单的创建来使用,可能还是会碰到一些问题.存在有什么问题呢?先来思考下,下面的这个接口,通过异步任务加速执行的实现,是否存在问题或风险呢? @RestController public class HelloController { @Autowired private AsyncTasks asyncTasks; @GetMapping("/hello&

问题描述 线上突然出现Dubbo超时调用,时间刚好为Consumer端设置的超时时间. 有好几个不同的接口都报超时了 第1次调用超时,第2次(或第3次)重试调用非常快(正常水平) Dubbo调用超时的情况集中出现了3次,每次都是过一会自动恢复 排查 排查日志 看到调用超时,首先就拿着traceId去服务提供方查日志. 奇怪的是,在服务提供方的业务日志里面,只有正常的调用日志(耗时正常),没有超时调用的日志. 从正常的调用日志里面看,一切都是正常的,看不出所以然. 给人的感觉就是超时那次请求的调用

在dubbo调用过程中被调用方有两个线程池:io线程池,业务线程池. 这也是dubbo调优的点. 配置信息: <dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /> Dispatcher all 所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等. direct 所有消息都不派发到线程池,全部

1.在xml中配置线程池 <!-- 配置线程池 --> <bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor"> <!-- 核心线程数 --> <property name="corePoolSize" value="4" /> <!--

一.配置jdbc.properties添加: #------------ Task ------------ task.core_pool_size=5 task.max_pool_size=50 task.queue_capacity=1000 task.keep_alive_seconds=60 二.配置Spring的applicationContext.xml添加: <bean id="taskExecutor" class="org.springframewor

jdk自带的原生的拒绝策略抛出的异常信息不够详细,而dubbo对拒绝策略进行了改写,抛出的信息更具有参考价值,值得我们借鉴. jdk自带的原生拒绝策略抛出的信息: // ThreadPoolExecutor的toString方法 /** * Returns a string identifying this pool, as well as its state, * including indications of run state and estimated worker and * tas

记一次线上dubbo服务超时和线程池满问题排查 可能调用的接口没问题,但是该服务中的其他接口占用完了线程池,导致调用超时被拒绝处理.

添加 Executor 在server.xml中的Service节点里面,增加executor节点,然后配置connector的executor属性,如下: <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="3000" minSpareThreads="5" maxSpareThreads="20" ac

示例: 1. 配置 @EnableAsync @Configuration public class TaskExecutorConfiguration { @Autowired private TaskExecutorProperties taskExecutorProperties; @Bean public Executor routeGen() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); execut

背景: 有一次在生产环境,突然出现了很多笔还款单被挂起,后来排查原因,发现是内部系统调用时出现了Hystrix调用异常.在开发过程中,因为核心线程数设置的比较大,没有出现这种异常.放到了测试环境,偶尔有出现这种情况,后来在网上查找解决方案,网上的方案是调整maxQueueSize属性就好了,当时调整了一下,确实有所改善.可没想到在生产环境跑了一段时间后却又出现这种了情况,此时我第一想法就是去查看maxQueueSize属性,可是maxQueueSize属性是设置值了.当时就比较纳闷了,为什么ma

首先了解一下dubbo线程模型 如果事件处理的逻辑能迅速完成,并且不会发起新的IO请求,比如只是在内存中记个标识.则直接在IO线程上处理更快,因为减少了线程池调度. 但如果事件处理逻辑较慢,或者需要发起新的IO请求,比如需要查询数据库,则必须派发到线程池,否则IO线程阻塞,将导致不能接收其他请求. 如果用IO线程处理事件,又在事件处理过程中发起新的IO请求,比如在连接事件中发起登录请求,会报“可能引发死锁”异常,但不会真死锁. 对于Dubbo集群中的Provider角色,有IO线程池(默认无界)

线上某dubbo服务A调用dubbo服务B的接口X方法,调用端A日志中出现了很多超时的情况,提供端B该接口X超时时间设置为60s: 查看提供端B的日志,报了很多线程池满的异常: Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-10.1.5.69:20914, Pool Size: 700 (active: 70

文章首发在公众号(龙台的技术笔记),之后同步到个人网站:xiaomage.info Hippo-4J 距离上一个版本 1.2.1 已经过去一个月的时间.在此期间,由 8 位贡献者 提交了 170+ commits,正式发布 1.3.0 版本. 注:这是一个 兼容历史版本 的重大升级. Github:https://github.com/mabaiwan/hippo4j Gitee:https://gitee.com/mabaiwancn/hippo4j HIPPO-4J 1.3.0 Featur

Dubbo默认的底层网络通讯使用的是Netty,服务提供方NettyServer使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 EventLoopGroup(worker) 来处理,boss和worker线程组我们称之为IO线程. 如果服务提供方的逻辑能迅速完成,并且不会发起新的IO请求,那么直接在IO线程上处理会更快,因为这减少了线程池调度. 但如果处理逻辑很慢,或者需要发起新的IO请求,比如需要查询数据库,则IO线程必须派发

目录 线程池配置模板 基础的注解解释 常用配置参数 配置类设计 线程池使用 ThreadPoolTaskExecutor源码 线程池配置模板 springboot给我们提供了一个线程池的实现,它的底层是由线程池ThreadPoolTaskExecutor来实现的.相较与JDK提供的线程池进行了一些功能的增强,比如对线程状态的监听,在我们在使用的时候更加的方便.在这里给各位同学一个配置模板,简单的讲解下Spring线程池的底层原理(在最后的源码章节). 基础的注解解释 @Configuration