問題描述:部門承接的某運(yùn)營(yíng)商的CRM項(xiàng)目日志查詢出現(xiàn)延遲愧捕，最高延遲達(dá)半小時(shí)，嚴(yán)重影響業(yè)務(wù)運(yùn)行孵奶。
問題解決:首先對(duì)他們的數(shù)據(jù)流向進(jìn)行了解后得知槐臀，數(shù)據(jù)是從Flume采集到Kafka再由Sparkstreaming到Elasticsearch, Elasticsearch做為數(shù)據(jù)存儲(chǔ)，版本為2.3.2畴蹭，CRM系統(tǒng)就是在前端對(duì)Elasticsearch進(jìn)行查詢坦仍，在此之前Elasticsearch集群出現(xiàn)過一次癱瘓，然后啟動(dòng)不起來(lái)叨襟，他們對(duì)Elasticsearch集群做過一次優(yōu)化繁扎，聽他們反應(yīng)之前是沒有延遲的，是集群優(yōu)化后出現(xiàn)了此問題。首先確定一下到底是哪個(gè)環(huán)節(jié)出現(xiàn)的問題梳玫，查看原始文件生成時(shí)間到Flume日志打印出來(lái)的時(shí)間爹梁，沒有出現(xiàn)延遲，kafka這塊采用了一個(gè)小工具叫KafkaOffsetMonitor提澎，監(jiān)控進(jìn)入kafka的速率和從kafka出的速率確認(rèn)kafka這塊的問題不大（順便說一下姚垃，給KafkaOffsetMonitor分配的java heap要大點(diǎn)，要不然數(shù)據(jù)太大的話界面會(huì)顯示不出來(lái)）盼忌，查看elasticsearch的入庫(kù)時(shí)間發(fā)現(xiàn)這塊有延遲积糯，那么問題就基本確定了，要不是sparkstreaming這塊處理的慢了谦纱，要不就是elasticsearch這塊入庫(kù)慢了看成。查看sparkstreaming任務(wù)發(fā)現(xiàn)還算穩(wěn)定因?yàn)槊颗稳蝿?wù)是一分鐘執(zhí)行一次，任務(wù)基本都在一分鐘之內(nèi)能夠完成跨嘉，對(duì)spark執(zhí)行命令和sparkstreaming程序做了些優(yōu)化侵佃，sparkstreaming這邊沒有太大改變蛉腌，高峰期延遲依然存在挎袜，那么問題就定位到elasticsearch上了况芒，對(duì)elasticsearch的cpu,io,內(nèi)存和gc的情況進(jìn)行檢查沒發(fā)現(xiàn)什么問題,查看配置文件發(fā)現(xiàn)常用的優(yōu)化點(diǎn)基本都涉及到了唠椭，問現(xiàn)場(chǎng)要優(yōu)化前的配置說沒有備份跳纳，只能一個(gè)一個(gè)配置項(xiàng)看，詢問現(xiàn)場(chǎng)每小時(shí)的數(shù)據(jù)量贪嫂，高峰期的話能達(dá)到2200多萬(wàn)寺庄，現(xiàn)在延遲基本就在高峰期的兩個(gè)時(shí)間點(diǎn)，一個(gè)是早上10點(diǎn)力崇，一個(gè)是下午4點(diǎn)斗塘，其余時(shí)間沒有延遲，經(jīng)過一個(gè)一個(gè)配置項(xiàng)排查亮靴，發(fā)現(xiàn)有個(gè)配置是index.translog.flush_threshold馍盟，值設(shè)置的是100000，查看官方文檔2.3.2版本配置說明茧吊， translog flush相關(guān)的配置項(xiàng)有index.translog.flush_threshold_size贞岭，默認(rèn)值為512mb，index.translog.flush_threshold_ops搓侄，默認(rèn)值為unlimited（也就是INT.MAX）瞄桨，index.translog.flush_threshold_period，默認(rèn)值為30m讶踪，index.translog.interval芯侥，默認(rèn)值為5s。沒有發(fā)現(xiàn)index.translog.flush_threshold這個(gè)配置項(xiàng)，后來(lái)看日志才知道這么設(shè)置的話代表index.translog.flush_threshold_ops這個(gè)配置項(xiàng)柱查，在這說明一下es 在每次進(jìn)行index或者delete操作后都會(huì)記錄到translog中廓俭，默認(rèn)是同步的，也就是每個(gè)request都會(huì)記錄到translog中并flush到磁盤物赶，通過修改index.translog.durability這個(gè)參數(shù)可以改為異步的白指，這個(gè)配置他們也改成了async，這個(gè)異步的執(zhí)行機(jī)制是先將每次的translog放到內(nèi)存buffer中酵紫，每5s（index.translog.interval）進(jìn)行一次檢查看是否滿足index.translog.flush_threshold_size告嘲，index.translog.flush_threshold_ops，index.translog.flush_threshold_period奖地，這三個(gè)條件中的一個(gè)橄唬，只要滿足就進(jìn)行一次flush操作將translog flush到磁盤,那么結(jié)合場(chǎng)景計(jì)算高峰期2200萬(wàn)每小時(shí)，平均1秒就有6000多次操作参歹，達(dá)到index.translog.flush_threshold_ops的100000也就十幾秒鐘仰楚，這個(gè)flush頻率有些快，影響效率犬庇，所以這塊用默認(rèn)值就可以僧界，然后我將index.translog.flush_threshold_size的值設(shè)置為1g，可能這塊重啟集群后測(cè)試臭挽，在高峰期沒有再出現(xiàn)延遲的情況捂襟。
總結(jié)：首先現(xiàn)場(chǎng)實(shí)施人員要對(duì)每次配置做備份，其次對(duì)每個(gè)優(yōu)化點(diǎn)進(jìn)行優(yōu)化時(shí)要針對(duì)自己實(shí)際業(yè)務(wù)的場(chǎng)景進(jìn)行優(yōu)化配置欢峰，不要盲目拷貝葬荷，還要對(duì)每個(gè)優(yōu)化配置項(xiàng)的含義進(jìn)行較深入的了解，這樣才能更好的利用好這些優(yōu)化點(diǎn)