FastDFS 4.08插入速度變得很慢

jiaomicha

如題，4.08，一個(gè)tracker, 5個(gè)group，每個(gè)group都是一臺(tái)機(jī)器，運(yùn)行了大概半個(gè)多月后插入數(shù)據(jù)的速率變得很慢（上傳一個(gè)幾兆的文件平均用大概兩分鐘）
使用client腳本上傳的速率也只有2M/s，求解釋啊

happy_fish100

磁盤(pán)要滿了？

jiaomicha

回復(fù) 2# happy_fish100


    沒(méi)有滿，storage里邊的配置是10%的reserve空間，但是那塊硬盤(pán)只用了40%左右，所以應(yīng)該不是這個(gè)問(wèn)題

happy_fish100

看看tracker和storage服務(wù)器的負(fù)載情況呢？

jiaomicha

回復(fù) 4# happy_fish100


    tracker那臺(tái)機(jī)器負(fù)載較輕，0.3左右；
    其他五臺(tái)storage的機(jī)器的負(fù)載在2-5之間，這幾臺(tái)機(jī)器上都部署有hadoop，不過(guò)hadoop的性能并沒(méi)有受到多大影響

happy_fish100

有使用合并存儲(chǔ)特性嘛？

jiaomicha

回復(fù) 6# happy_fish100


    沒(méi)有用trunk合并。
    和一個(gè)群里的童鞋聊了聊，后來(lái)發(fā)現(xiàn)tracker中的默認(rèn)配置
# the method of selecting group to upload files
# 0: round robin
# 1: specify group
# 2: load balance, select the max free space group to upload file
store_lookup=2

是每次都選擇有最大空閑空間的group上傳。
我們的系統(tǒng)中后來(lái)就加了幾個(gè)group，導(dǎo)致各個(gè)group之間的空閑空間相差很大，所以客戶端每次總是連到了同一個(gè)group（我們每個(gè)group只有一個(gè)storage）
可能是這個(gè)原因?qū)е略搒torage的TCP連接暴增，插入數(shù)據(jù)結(jié)束后又處于TIME_WAIT，其他客戶端連接就有問(wèn)題了。

現(xiàn)在改成了0輪詢(xún)了。速度恢復(fù)正常。

問(wèn)一個(gè)問(wèn)題，如果現(xiàn)在開(kāi)啟trunk合并的話，只有這之后的文件上傳才會(huì)合并吧？之前的都保持原樣嗎？

happy_fish100

是的。