看板Soft_Job
作者stevekevin10 (steve)
標題[請益] 資料庫connection太多導致回應變慢
時間2022-07-22 03:21:55
工作上遇到了一個找不太到原因的狀況 語言: 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 請各位大大提供點看法 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 219.85.180.114 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1658431317.A.D01
推 drajan: 看 DB concurrency query的數量 DB很常成為瓶頸07/22 04:23
推 keel90135: 你這個一定要try跟看才知道，沒有資深的同事可以問嗎?07/22 04:32
推 sniper2824: 業務邏輯一定要查這麼多次？07/22 06:23
→ bill0205: 八成DB Query太過於頻繁 不然200次太誇張07/22 06:36
→ day831231: 1 個 Endpoint call那麼多次，我猜可能是 N+1 queries07/22 07:19
推 Toth: 有人被洋鬼子包養過嗎07/22 07:19
→ choYM: Pool設定沒寫出來 db開多少個connection給妳也沒說 大家也07/22 07:22
→ choYM: 只能隔空抓藥啊… 另外這兩個entrypoint 要打那麼多次sql也07/22 07:22
→ choYM: 蠻怪的…07/22 07:22
推 s06yji3: 是一個request會query DB 200次嗎？用endpoint 打DB幾次07/22 07:36
→ s06yji3: 很不精確...07/22 07:36
推 Asterix: 到底要多有錢才會想包養07/22 07:36
推 jack0204: 我猜這是n+1的問題，不然怎麼可能打這麼多次07/22 07:39
推 ricestand: 大概就n+1了07/22 08:40
推 godddddd: 200個指令長怎樣 看能不能減少07/22 08:42
推 bill0205: 我也覺得是N+1 如果是mysql 就看slow log07/22 08:48
→ ntpuisbest: https://i.imgur.com/U8cJUgu.jpg07/22 09:23
推 AdamShi: 閨蜜上包養網還推薦我...07/22 09:23
→ ntpuisbest: 看一下有沒有在loop裡面查sql07/22 09:24
→ iamshiao: 可以想想有沒辦法把 200次濃縮成一次07/22 10:22
→ iamshiao: 新功能有改 DB 結構嗎？ 用預存程序跑嗎？ 可以清掉執07/22 10:24
→ iamshiao: 行計畫再跑看看07/22 10:24
→ yfr: 原來是debug，我還以為是通靈，以下開放第一屆天下通靈大會07/22 10:34
推 lezabo: 包養?07/22 10:34
推 WaterLengend: 打這麼多次要不要先濃縮看看07/22 11:07
推 ChungLi5566: 請DBA幫忙看 有工具可以監控SQL指令效率 07/22 11:19
噓 MoonCode: 看內文不懂你如何推論並猜測conn過多07/22 12:45
→ worf: =.=07/22 12:54
→ Uzak: N+107/22 13:07
推 silberger: 現在包養網都這麼直接嗎07/22 13:07
→ MonyemLi: 雖然不好但也還好，n+1的對象基本上是pk查詢。這該不是07/22 13:40
→ MonyemLi: 主要原因07/22 13:40
噓 s06yji3: 資訊太少，補噓一下。上班已經在通靈了。07/22 13:53
推 guanting886: DB沒這麼弱啦.. 若單純是 select 有正常打上索引、07/22 13:58
→ guanting886: 有用到主鍵，query 時間都<1ms07/22 13:58
推 xayile: 歐美包養真的很平常嗎?07/22 13:58
推 guanting886: 建議先用EXPLAIN語法去檢查一下07/22 14:02
推 gmoz: 懷疑connection數量 不會直接下指令看連線數嗎07/22 15:09
推 mathrew: T-SQL寫太爛吧07/22 19:24
→ mathrew: 先確認執行計畫的狀況07/22 19:25
→ KY1998: 不知道業務規模，如果這個表資料只有1萬筆內，直接查全部07/22 23:01
推 cazo: 男友上包養網 該放生嗎07/22 23:01
→ KY1998: 再用key去查詢07/22 23:02
→ dark10108: 會不會query一直建新的connection07/23 00:33
→ dark10108: 或connection pool的idle time設定太短 07/23 00:34
→ alan3100: 從DB查不就好了 幹嘛在那蝦矇猜問題 07/23 02:04
推 fifi82726: DB就是這麼脆弱 請優化200個query的部分 07/23 13:04
推 izilo: 是這個包養平台嗎 07/23 13:04
→ ChungLi5566: 有DB的監控工具可以用 不用這樣瞎猜 07/23 14:44
→ ChungLi5566: 可以看到每個階段耗費幾毫秒 07/23 14:44
→ lchcoding: 讀了你的更新，我只對Q1.2感興趣 07/23 21:33
→ lchcoding: 在B裡面加些log,準備做時間分析 07/23 21:33
→ lchcoding: 然後跑（未加新功能）前，所謂正常狀況，跟（加新功能 07/23 21:33
推 SEDAP: 交男友跟包養有什麼差別 07/23 21:33
→ lchcoding: ）後，你所謂的變慢，請先回答慢在哪裏，解bug的方向才 07/23 21:33
→ lchcoding: 會出來.用射擊法解Bug,情緒常常會像心電圖那樣.還有一 07/23 21:33
→ lchcoding: 種方法是用圍捕的 07/23 21:33
噓 pttano: 不是db太慢是你的code太爛，不是多條魚是多餘你 07/24 19:09
→ pttuser2266: 有沒有加欄位，or 改 table schema, 1 個 sql query 07/24 23:08
推 TUZom: 包養網到底在紅什麼? 07/24 23:08
→ pttuser2266: 慢 1ms, 1000次就慢一秒了 07/24 23:08
→ acgotaku: 你有做讀寫分離嗎 07/25 09:45
→ acgotaku: 而且你這情況 八成是每次任務都創建一個連線 07/25 09:47
推 hegemon: 會搞到N+1通常的code寫得爛.. 07/25 11:15
→ acgotaku: 你db用同一台呀 你去打B的時候 監測db server的cpu,mem 07/25 14:43
推 Jiulon: 有人被包養嗎 07/25 14:43
推 drajan: 因為你A跟B有共用的 component 也就是DB 你沒有其他工作上 07/25 16:56
→ drajan: 的資深工程師可以問嗎？任何一個有點程度的應該都可以看得 07/25 16:56
→ drajan: 出來問題在哪裡 07/25 16:56
推 internetms52: connection pool 不夠大是有log可以看的，如果是a 08/18 06:57
→ internetms52: 的進行過程中b變慢，那應該存在一個很長且耗資源的 08/18 06:57
推 laetuon: 求包養...管飽就好XD 08/18 06:57
→ internetms52: 查詢在前一個未結束前，不斷累積 08/18 06:57
推 internetms52: table lock 也有可能是讓短查詢變長的原因 08/18 07:14