??對(duì)dubbo的服務(wù)治理管理頁(yè)面澳腹,有人查詢已經(jīng)上線的服務(wù)十分慢晚唇,甚至要5巫财,6分鐘才返回結(jié)果,但有些查詢得時(shí)間比較正常哩陕。
??由于是第一次接手這個(gè)項(xiàng)目平项,并不知到其中的原理赫舒,怎么實(shí)現(xiàn)查詢的,有使用到zk加數(shù)據(jù)庫(kù)的查詢闽瓢。大致判斷應(yīng)該是這兩個(gè)耗時(shí)很長(zhǎng)導(dǎo)致的接癌。
??接下來(lái)當(dāng)然是開(kāi)始在本地運(yùn)行這個(gè)項(xiàng)目,好不容易跑起來(lái)扣讼,該怎樣入手了缺猛?
??首先,模擬用戶的搜索椭符,試了好幾個(gè)dubbo接口荔燎,查詢的速度都正常,好不容易找到一個(gè)時(shí)間返回很長(zhǎng)的销钝,開(kāi)始調(diào)查有咨。
??既然使用到的是tomcat,一般來(lái)說(shuō)接口也是同步返回的蒸健,沒(méi)有另開(kāi)線程返回異步結(jié)果座享,所以找到idea debugger下的所有線程。使用的是tomcat似忧,tomcat開(kāi)的線程用戶請(qǐng)求渣叛,都是http-nio-{{port}}-exec-{{index}},找到其線程前綴盯捌,發(fā)現(xiàn)一個(gè)線程的狀態(tài)一直是RUNNING淳衙,對(duì)其右鍵,選擇suspend挽唉,暫停此線程滤祖。發(fā)現(xiàn)其卡在io的連接上,看到其調(diào)用棧瓶籽,考到項(xiàng)目本身類所在的線程棧匠童,發(fā)現(xiàn)是一個(gè)調(diào)用sql接口。
接下來(lái)就是復(fù)現(xiàn)了塑顺。復(fù)制其線程站傳遞給數(shù)據(jù)庫(kù)的參數(shù)汤求,構(gòu)造相對(duì)應(yīng)的語(yǔ)句,發(fā)現(xiàn)其運(yùn)行了5分鐘半才得到結(jié)果严拒,至此原因找到了扬绪,是sql select出了問(wèn)題,由于有些dubbo讀物并沒(méi)有手動(dòng)設(shè)置group這時(shí)會(huì)手動(dòng)指定其group為dubbo裤唠,而數(shù)據(jù)庫(kù)數(shù)據(jù)又很多挤牛,根據(jù)group查詢其結(jié)果超過(guò)100萬(wàn)條(),結(jié)果十分巨大种蘸。所以十分耗時(shí)墓赴,造成結(jié)果查詢很慢竞膳。