作者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/m.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