??對(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é)果查詢很慢竞膳。
