tomcat 的 maxThreads 和 maxConnections 有没有建议值啊

[luxinfl]

有个 8C32G 的服务器，部署了一个 springboot 服务，只有一个接口，这个接口执行时间正常大概 1ms 的样子（可能 1 毫秒都不到，接口具体逻辑就是往一个 LinkedBlockingQueue offer 数据，然后会有个定时任务把这个队列的数据写入 hbase ）。经常每天都有>780ms 并且次数>100 的超时告警。

现在默认设置是 maxThreads=200 maxConnections=10000 ，我在想是不是可以调大一点线程数，因为看了 cpu 和内存占用都蛮低的。 有看过一个帖子说 1C4G 建议 200 并发，4C8G 建议 800 并发。。

暂时没有 tomcat 运行时的日志信息，还没打印，有什么手段可以排查这个高时延么。接口每天大概 2.7 亿调用量。

还发现一个奇怪的状况，我在测试环境压测，activeCount 还没到核心线程池的数量，然后队列就已经有数据了，这是个什么情况。按理说没到核心线程数队列不改有数据。是打印日志那一刻有问题么。。

[roundgis]

換用 g1gc 看看

[xxfye]

首先要判断一下，这个超时是哪方面的超时？
是线程池不够来引起的？扩大线程池。
还是垃圾回收引起的？换 G1 或 ZGC 。
还是是队列被阻塞引起的？换队列实现，或者用 ThreadLocal 多队列。

[oldshensheep]

用 java19 virtual thread 。。。
开玩笑的，因为你还不知道为什么超时，可以参考楼上的。我觉得应该是队列的问题，可能满了。

[securityCoding]

最高 qps 呢

[FrankAdler]

一毫秒的意思就是一个线程 1 秒能处理 1000 个请求，每天 2.7 亿平均一秒 3k ，算上峰谷不等，我觉得你线程数开 10 个就够了
所以我建议你学学怎么排查慢请求

[imv2er]

极极极大概率是没及时写入 hbase ，queue 满了 和 tomcat 无关

[luxinfl]

@xxfye 怀疑是 tomcat 的默认设置的问题，这个要等部署后才能看到线程池的运行信息。
垃圾回收都是默认设置的，这个问题不大。
队列阻塞应该不会，因为用的 offer 方法存数据，不存在锁，存不进去直接丢弃了。

[luxinfl]

@securityCoding 应该有七八千吧

[luxinfl]

@imv2er queue 满了的话，接口会直接返回不阻塞。

[yc8332]

不是说开越多越快。

[luxinfl]

@FrankAdler 没啥头绪啊。。。。

[securityCoding]

大概率是 gc 引起的，重点查这个方向

[Vaspike]

推荐 Spring boot admin 这个 actuator

[tianmalj0613]

服务接入一下 prometheus ，或者其他监控工具，把系统的指标存下来才能定量定性分析。
有数据之后，用 UI 工具，比如 grafana 展示成图表就知道问题了

[Chinsung]

看这个描述，看下内存使用情况，大概率是 GC 导致的

[angryfish]

缺相关监控很难直接判断，安照经验应该大概率是 full GC 了

[luxinfl]

@securityCoding
@Chinsung
@angryfish
我用 jstat 看了下，还真是，咋测的时候一秒一次 ygc ，大概停顿 10 几毫秒的样子