4
基于Dubbo2.5.8版本压测，线程池配置分别为fixed以及cached模式，总线程数量为200，并发数梯度增长到100多之后，后台work线程数始终维持在10个左右，其他线程都处于wating状态。
Q
[apache/dubbo]Dubbo 2.5.8版本压测线程配置池为fixed以及cached，工作线程数量很少
A
回答
5
你的问题是什么，我不明白。你说concurrent increase to 100的消费者并发 100 个请求是什么意思？首先，检查其他资源是否限制了整个流量。
7
@chickenlj，谢谢回复，我的问题是，压测场景，并发数梯度增长到tps峰值之后，打印线程stack日志，此时总线程数200多(包括IO和请求处理线程)，但是runnable状态的线程数始终维持在10个左右，大部分均处于waiting (parking)状态，此时继续增加并发，tps会下降，并且响应时间会增长，线程处理机制不太合理，正常的机制应当是将waiting的线程释放来处理更多的请求。 为了验证是否为Dubbo框架的问题，我们使用了淘宝的专门针对Dubbo的压测工具，并且搭建简单的Dubbo服务进行压测，压测结果和Dubbo官网基本一致，并且work线程数仍然固定在10个左右，将consumer端connector数调整为20(原始值为1)，tps会有部分增长，work线程数也会有适当增长，但是和connector增长数不是线性增长。
8
你说的work线程是指netty的worker线程，还是server端请求处理线程？测的时候netty3和netty4都是这样的情况吗？@rentian870423
1
| server端的业务处理线程数 @zhaojigang Dubbo2.5.3以及Dubbo2.5.8均是这种现象，没关注netty版本。 压测时查看线程对战，发现日志打印会有部分影响(log4j1以及logback)，修改成log4j2，之后，性能有所提升，但是work线程数占比仍然不高。 如下为各种状态线程占比。 Status | Number of Threads : 237 | Percentage |
|---|---|---|
| Deadlock | 0 | 0 (%) |
| Runnable | 29 | 12 (%) |
| Waiting on condition | 200 | 84 (%) |
| Waiting on monitor | 4 | 2 (%) |
| Suspended | 0 | 0 (%) |
| Object.wait() | 3 | 1 (%) |
| Blocked | 1 | 0 (%) |
| Parked | 0 | 0 (%) |
如下为某一waiting线程栈，处于等待任务的状态： ubboServerHandler-10.10.56.20:7778-thread-111" daemon prio=10 tid=0x00007f20584d6800 nid=0x5cb waiting on condition [0x00007f2052cab000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method)
-
parking to wait for <0x0000000781f949d0> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:957) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917) at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
0
@chickenlj ，如果处于等待新请求的状态，压测时，加大并发数量，TPS应该有所上升，现状是，加大并发数量，tps并无明显变化，work状态的线程数仍然维持在10个左右
3
@rentian870423 请问你们这个问题最后怎么解决的？
1
@longer3 ,没解决，猜测和Dubbo的线程模型有关，Dubbo框架使用的建议是，consumer和provider的应用比例应该是N：1，在实际压测时，通过调试connections的数量，确实可以影响work的线程数，不过不是线性增长，硬件资源使用率有所提升，但是还是未压满。和压测工具也有一定关系，jemeter的压测结果相对loadrunner稍微好一点，通过线程堆栈分析，感觉瓶颈还是在日志输出，但是作为应用，不不可能完全摒弃日志，所以无法做到最佳调优，只能是研发和运维结合着考虑。
3
我也遇到了，修改dispatcher="mesage"，生产环境部署上去之后还是很快就占满了，jstack dump之后没发现dubbo的200个线程都在waiting，实际查看日志调用发现只有那么几个线程在处理业务，其他的就是在waiting，dubbo版本从2.5.10升级到2.6.8也不管用
8
同。。 30个线程running 200个线程waiting