iT邦幫忙

0

網站多人使用會卡住,該如何找出問題?

  • 分享至 

  • xImage

公司的網站平常都很快,做直播的時候,網站速度也沒變慢,
但只要主持人說開始商品搶購,網站就會非常慢,按個鈕會沒反應,好幾秒後網頁才會動,
因此覺得可能是sql方面的問題,想查是哪個部份被lock了,
用jmeter模擬一秒同時80人進網頁,連續執行10次,
同時用下列語法查詢sql中被lock的物件:

SELECT request_session_id AS spid,
    resource_type AS rt,
    resource_databASe_id AS rdb,
    (CASE resource_type 
    WHEN 'OBJECT' then object_name(resource_ASsociated_entity_id) 
    WHEN 'DATABASE' then 'DB' 
    ELSE 
    (SELECT object_name(object_id) FROM sys.partitions 
        WHERE hobt_id = resource_ASsociated_entity_id) END) AS objname,
    resource_description AS rd,
    request_mode AS rm,
    request_status AS rs,*
FROM sys.dm_tran_locks 
where request_mode in ('x','ix')

但查出的7、80筆紀錄大部份都是:
https://ithelp.ithome.com.tw/upload/images/20221124/20125321IF3q6UwYrg.jpg

欄位「objname」物件名稱都是nulL,我還是不知道是哪邊出問題,
請問我這樣子查是ok的嗎?還是我的做法不對?該怎麼找出網站卡住的問題呢??

看更多先前的討論...收起先前的討論...
沒用交易程序 ?
請參考 SQL交易程序,他專門用來處理大量寫入要求的資料庫鎖定動作,必須完成每一筆交易才能繼續下一筆交易
接下來就是程式控制的部分,你的後端應該要有偵測機制,每一批最多幾次要求
例如一百次,我們就當作你每次就是只接受一百次的搶購,超過一百次會自動拋棄,這也是SQL 交易程序可以設定的參數
幫樓主餵狗,大量觸發,是很常見的
https://www.google.com/search?q=SQL+交易程序
接下來就是看你主機的IO能力,我講一百次是很基本的,如果你要上千次上萬次,你要看你IO的速度,假如每筆資料10KB就好,一百次是 1MB,HDD就能在幾秒內處理完畢,但是 一萬次是 100MB,你要幾秒內處理完畢,HDD可能就不太能負擔了
大哉問,追蹤等真●高手的答案
wiseguy iT邦超人 1 級 ‧ 2022-11-24 23:03:55 檢舉
你沒寫出你的「搶購」程序,沒人會知道為什麼卡住。
不過如果你的「搶購」程序,就是按照一個人進來購買這樣下去思考與執行。那麼99%會因為多人同時搶購而卡住無誤。
光是去思考實際例子:不要說一百個人,光是十個人同時要在小七櫃台前結帳,不卡住嗎?
你會問這個問題 表示你對大併發的處理沒有概念,
大併發的應用不能用一般傳統的寫程式方式處理,技術上非常複雜.
這也是為什麼台灣一堆購物網站幾乎都沒辦搶購的主因,大多數傳統網站的設計還是在CRUD的觀念上進行,這種做法是無法解決大併發的問題
fillano iT邦超人 1 級 ‧ 2022-11-25 07:47:40 檢舉
不要「因此覺得可能是XXX方面的問題」,先在程式裡面埋log記錄時間,或是用工具來分析程式執行的時間等等,有了數據,再來看問題。
你的問題大致上可以定位出是資料庫無法瞬間乘載太多數的請求導致,瓶頸應該是在資料庫的IO,
在不改程序的解決方式就是提升IO速度譬如改用SSD,
但這只是治標不治本,如果你的用戶數量是可預期的這種方式可能可以解決,但如果人數還會成長,那麼還是有瓶頸
studycode iT邦新手 5 級 ‧ 2022-11-25 16:19:10 檢舉
公司網站的使用者目前還不多,直播最後的搶購不會超過100人,對於這種量,硬體設備或是server頻寬應該都不會有太大的影響,因一個月才一次搶購活動,我現在做任何調整都不知是否真的有改善,都是等下次活動才能看網站是不是又卡住了,那目前調的是都沒改善。
to 窮嘶發發發:網頁只有很小部份用到交易,想說用交易不是會把資料鎖住,更會卡嗎?
to wiseguy:沒錯,確實是以一個人的訂購流程來思考,搶購活動是近期才開始,才發現網站不堪負荷。
to programlin:我確實沒有大併發的概念,因網站已架設多年,對於防超賣及會員各種的折價、會員資格、可用多少回饋...邏輯很複雜,所以會希望在盡量不更動程式的狀況下,看有什麼方法做改善,不然可能就是架構要大改了。
to fillano:程式埋log我下次試試,看每段sql的執行時間;也想找工具看數據再來查問題,這次就是先用jmeter模擬,想看是否有table lock,只是我連結果都看不懂~~^^
to programlin:同事之前不曉得怎麼查的,他說當下的負荷量很小,硬體是足以應付的,且網站使用者不多,怎麼才幾個人就讓網站這麼卡,不知該怎麼查問題。
untitled iT邦新手 5 級 ‧ 2022-12-03 09:14:31 檢舉
可以看一下資料庫CPU排行報表看哪些語法排行前幾名
看語法能不能調整、sql語法加入索引看能不能改善搜尋速度、層面有點廣,資料庫主機的規格、AP主機的規格..等等
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
0
whitefloor
iT邦研究生 2 級 ‧ 2022-11-24 16:00:29

你可以用slow query看是哪段出問題

studycode iT邦新手 5 級 ‧ 2022-11-25 16:20:43 檢舉

sql server 好像沒這功能~?

1
I code so I am
iT邦高手 1 級 ‧ 2022-11-25 09:29:26

懷疑是資料庫處理過慢,有許多方式可以改善:

  1. 兩段式處理:接單/處理訂單分開處理,接單只寫入交易記錄,不作其他處理,另寫一隻程式專門處理訂單,處理完再email通知客戶。
  2. 使用 redis 或 其他 cache server.
  3. 加大 database connection pool.
studycode iT邦新手 5 級 ‧ 2022-11-25 16:32:15 檢舉

嗯~可以考慮把接單跟開單分開,目前開單才會更新會員跟商品的相關數據,會員若直接再下另一筆單,才會查到他的最新資料,會影響他可買哪些商品,要改成分開也是個大工程,會列入討論。

0
Ks
iT邦新手 3 級 ‧ 2022-11-25 17:31:19

這個用微服務和消息隊列來進行優化和程式提升

使用redis來記錄庫存, 有人下單就扣和判斷庫存

扣除成功之後, 把資料寫到消息隊列Message queue去進行後續處理
這樣就完全可以避開了請求太多的問題了

studycode iT邦新手 5 級 ‧ 2022-11-28 15:39:12 檢舉

謝謝,我先來了解一下redis是什麼東西。

Ks iT邦新手 3 級 ‧ 2022-11-28 17:41:36 檢舉

給點意見, 可以從這幾個方面去思考和改進代碼:

  1. 如果是讀取資料緩慢就考慮用Redis做中間緩存, 不然所有用戶同時間擠著進來絕對把你的數據庫打趴了

  2. 流量大需要有load balancer去分擔流量, K8S就有很好的調度功能了, 當流量大的時候pods會auto scaling, 然後內部也有實現load balancer功能, 當然简单的话, 就用nginx也能做到load balancer

  3. 程式內解藕 loosing couple, 不要一堆邏輯擠著一個function裡面執行, 可以學下消息隊列message queue把業務拆分

  4. 做這類型網站上線之前做好是做好壓測QPS等等

0
海綿寶寶
iT邦大神 1 級 ‧ 2022-11-26 22:53:22

參考以下觀念圖
https://ithelp.ithome.com.tw/upload/images/20221126/20001787KvNh5XCMrg.png
參考以下架構圖
https://ithelp.ithome.com.tw/upload/images/20221126/20001787PwKMao75jm.png

如果有美國時間的話
就研究一下尚硅谷 尚品匯

studycode iT邦新手 5 級 ‧ 2022-11-28 15:43:58 檢舉

好的,謝謝~~還挺複雜的^^,但這幾天不只一人提到圖裡面的redis,我應該會先看看redis可以怎麼跟目前的系統做搭配

我要發表回答

立即登入回答