作者stevekevin10 (steve)
看板Soft_Job
标题[请益] 资料库connection太多导致回应变慢
时间Fri Jul 22 03:21:55 2022
工作上遇到了一个找不太到原因的状况
语言: Java mybait
新增了一个功能後
endpoint A:
下面有一个method大概会打DB query 200次
这时
endpoint B 的repsonse也跟着大幅增加 (endpoint B会打DB约1000次）
这有什麽可能的原因造成的呢？
* endpoint B 没有去call 新的method 没有增加query次数
* 有怀疑是connection pool 爆掉
但不知道该如何debug
且当我部署完 没去call A的时候
单纯call B速度也一样变慢（没有call A应该没有建立connection….吧？）
更新*
的确是n+1问题没错
但我困惑的不是该如何解决...
而是为什麽n+1的地方在method A但B会影响
我会觉得是connection pool的问题是因为
执行B的时候并没有跑到A那段的code
他这里面不会有一些slow query的情况
目前唯一能想到的就只有
1.
可能打A的时候connection pool 被占满了
打B要重建导致速度变慢
Q1.1 不确定mybaits打不同表的connection是不是要重建？还是一样重pool里面捞就好
Q1.2 刚部署到新机器上後，没call过A单纯call B也变慢
2. DB被太多query连线导致速度变慢
Q2.1理论上DB应该没有那麽弱...而且他是在测试环境 只有我当下的单条request
Q2.2 同1.1
怪哉 T.T
请各位大大提供点看法
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 219.85.180.114 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1658431317.A.D01.html
1F：推 drajan: 看 DB concurrency query的数量 DB很常成为瓶颈07/22 04:23
2F：推 keel90135: 你这个一定要try跟看才知道，没有资深的同事可以问吗?07/22 04:32
3F：推 sniper2824: 业务逻辑一定要查这麽多次？07/22 06:23
4F：→ bill0205: 八成DB Query太过於频繁 不然200次太夸张07/22 06:36
5F：→ day831231: 1 个 Endpoint call那麽多次，我猜可能是 N+1 queries07/22 07:19
6F：→ choYM: Pool设定没写出来 db开多少个connection给你也没说 大家也07/22 07:22
7F：→ choYM: 只能隔空抓药啊… 另外这两个entrypoint 要打那麽多次sql也07/22 07:22
8F：→ choYM: 蛮怪的…07/22 07:22
9F：推 s06yji3: 是一个request会query DB 200次吗？用endpoint 打DB几次07/22 07:36
10F：→ s06yji3: 很不精确...07/22 07:36
11F：推 jack0204: 我猜这是n+1的问题，不然怎麽可能打这麽多次07/22 07:39
12F：推 ricestand: 大概就n+1了07/22 08:40
13F：推 godddddd: 200个指令长怎样 看能不能减少07/22 08:42
14F：推 bill0205: 我也觉得是N+1 如果是mysql 就看slow log07/22 08:48
16F：→ ntpuisbest: 看一下有没有在loop里面查sql07/22 09:24
17F：→ iamshiao: 可以想想有没办法把 200次浓缩成一次07/22 10:22
18F：→ iamshiao: 新功能有改 DB 结构吗？ 用预存程序跑吗？ 可以清掉执07/22 10:24
19F：→ iamshiao: 行计画再跑看看07/22 10:24
20F：→ yfr: 原来是debug，我还以为是通灵，以下开放第一届天下通灵大会07/22 10:34
21F：推 WaterLengend: 打这麽多次要不要先浓缩看看07/22 11:07
22F：推 ChungLi5566: 请DBA帮忙看 有工具可以监控SQL指令效率 07/22 11:19
23F：嘘 MoonCode: 看内文不懂你如何推论并猜测conn过多07/22 12:45
24F：→ worf: =.=07/22 12:54
25F：→ Uzak: N+107/22 13:07
26F：→ MonyemLi: 虽然不好但也还好，n+1的对象基本上是pk查询。这该不是07/22 13:40
27F：→ MonyemLi: 主要原因07/22 13:40
28F：嘘 s06yji3: 资讯太少，补嘘一下。上班已经在通灵了。07/22 13:53
29F：推 guanting886: DB没这麽弱啦.. 若单纯是 select 有正常打上索引、07/22 13:58
30F：→ guanting886: 有用到主键，query 时间都<1ms07/22 13:58
31F：推 guanting886: 建议先用EXPLAIN语法去检查一下07/22 14:02
32F：推 gmoz: 怀疑connection数量 不会直接下指令看连线数吗07/22 15:09
33F：推 mathrew: T-SQL写太烂吧07/22 19:24
34F：→ mathrew: 先确认执行计画的状况07/22 19:25
35F：→ KY1998: 不知道业务规模，如果这个表资料只有1万笔内，直接查全部07/22 23:01
36F：→ KY1998: 再用key去查询07/22 23:02
※ 编辑: stevekevin10 (223.140.170.71 台湾), 07/22/2022 23:39:34
37F：→ dark10108: 会不会query一直建新的connection07/23 00:33
38F：→ dark10108: 或connection pool的idle time设定太短 07/23 00:34
39F：→ alan3100: 从DB查不就好了 干嘛在那虾蒙猜问题 07/23 02:04
40F：推 fifi82726: DB就是这麽脆弱 请优化200个query的部分 07/23 13:04
41F：→ ChungLi5566: 有DB的监控工具可以用 不用这样瞎猜 07/23 14:44
42F：→ ChungLi5566: 可以看到每个阶段耗费几毫秒 07/23 14:44
43F：→ lchcoding: 读了你的更新，我只对Q1.2感兴趣 07/23 21:33
44F：→ lchcoding: 在B里面加些log,准备做时间分析 07/23 21:33
45F：→ lchcoding: 然後跑（未加新功能）前，所谓正常状况，跟（加新功能 07/23 21:33
46F：→ lchcoding: ）後，你所谓的变慢，请先回答慢在哪里，解bug的方向才 07/23 21:33
47F：→ lchcoding: 会出来.用射击法解Bug,情绪常常会像心电图那样.还有一 07/23 21:33
48F：→ lchcoding: 种方法是用围捕的 07/23 21:33
感谢 太疑惑忘记基本的方法找问题了T_T
49F：嘘 pttano: 不是db太慢是你的code太烂，不是多条鱼是多余你 07/24 19:09
50F：→ pttuser2266: 有没有加栏位，or 改 table schema, 1 个 sql query 07/24 23:08
51F：→ pttuser2266: 慢 1ms, 1000次就慢一秒了 07/24 23:08
52F：→ acgotaku: 你有做读写分离吗 07/25 09:45
53F：→ acgotaku: 而且你这情况 八成是每次任务都创建一个连线 07/25 09:47
54F：推 hegemon: 会搞到N+1通常的code写得烂.. 07/25 11:15
楼上有几位别火气那麽大～
我的问题一直不是在该怎麽解决速度
或是为什麽这样打速度会变慢
主要问题是疑惑为啥改A会影响到B速度
※ 编辑: stevekevin10 (219.85.180.114 台湾), 07/25/2022 12:28:02
55F：→ acgotaku: 你db用同一台呀 你去打B的时候 监测db server的cpu,mem 07/25 14:43
56F：推 drajan: 因为你A跟B有共用的 component 也就是DB 你没有其他工作上 07/25 16:56
57F：→ drajan: 的资深工程师可以问吗？任何一个有点程度的应该都可以看得 07/25 16:56
58F：→ drajan: 出来问题在哪里 07/25 16:56
59F：推 internetms52: connection pool 不够大是有log可以看的，如果是a 08/18 06:57
60F：→ internetms52: 的进行过程中b变慢，那应该存在一个很长且耗资源的 08/18 06:57
61F：→ internetms52: 查询在前一个未结束前，不断累积 08/18 06:57
62F：推 internetms52: table lock 也有可能是让短查询变长的原因 08/18 07:14