此時OpenTSDB沒有內(nèi)置緩存（除了將緩存PNG圖像文件60秒的內(nèi)置GUI）。因此只能依靠底層數(shù)據(jù)庫的緩存。在HBase（最常見的OpenTSDB后端）中，有一個塊緩存的概念，它可以在寫入 和/或 讀取時在內(nèi)存中存儲行和列的塊。Nick Dimiduck的Block Cache 101是一個很好的入門書。設(shè)置緩存的一個好方法是使用BucketCache緩存并將L1緩存大小設(shè)置得相當(dāng)大，這樣它就可以充當(dāng)寫緩存并將大部分最新數(shù)據(jù)保存在內(nèi)存中。然后，當(dāng)用戶運行查詢時，L2緩存可以將經(jīng)常查詢的數(shù)據(jù)保存在內(nèi)存中。
仔細(xì)觀察region server的GC暫停。用戶通常在堆外模式下運行bucket cache，但在堆外緩存命中和寫入操作中，Java和JNI之間的序列化操作仍有一定的代價。
另外，請確保HBase表已啟用壓縮。塊使用表中指定的壓縮算法存儲在內(nèi)存中，因此與未壓縮的塊相比可以將更多壓縮塊放入緩存中。
如果通常在某個指標(biāo)中查找一個或兩個時間序列的查詢（即多個標(biāo)簽值不同），請確保使用了2.3或更高版本且在查詢中啟用了explicitTags。查詢必須列出與正在查找的數(shù)據(jù)相關(guān)聯(lián)的所有標(biāo)簽key，但它會啟用HBase上的特殊過濾器，這將有助于減少掃描的行數(shù)。詳情請參閱查詢過濾器。
或者，如果在指標(biāo)名稱中放置高基數(shù)的標(biāo)簽，這將大大減少查詢時掃描的數(shù)據(jù)量并提高性能。請參閱編寫數(shù)據(jù)以獲取更多信息
對于將許多時間序列聚合在一起的查詢，提高性能的最佳方法是在啟用salting的情況下運行OpenTSDB 2.2或更高版本，并在HBase集群中運行多個regionserver。這將并行執(zhí)行查詢，從每個regionserver獲取數(shù)據(jù)子集并合并結(jié)果。例如，對于單個regionserver，查詢可能需要10秒才能完成。使用salting將相同的數(shù)據(jù)寫入5個regionserver時，相同的查詢大約花費2秒，它是由最慢的regionserver響應(yīng)所需的時間決定的。合并集合通常是微不足道的。
如果在TSD和消費應(yīng)用程序（例如UI或API客戶端）之間觀察到瓶頸，那么查看寬時間范圍（例如幾個月或幾年）的查詢可以使用降采樣，并從中受益。使用降采樣器將減少由TSD序列化并發(fā)送給用戶的數(shù)據(jù)量。
但是，如果存儲（HBase）和TSD之間存在瓶頸，那么最好的解決方案是使用OpenTSDB 2.4或更高版本開始寫入上卷數(shù)據(jù)。這需要外部系統(tǒng)計算基于時間的上卷并將其寫入存儲。或者，UI或API客戶端可針對較小時間范圍跨度的多個TSD執(zhí)行多個查詢并將結(jié)果合并在一起。未來我們計劃直接向TSD添加這些功能。
需要考慮的其他事項：
運行多個專用于讀取數(shù)據(jù)的TSD，并在它們的前面放置負(fù)載均衡器。這是運行OpenTSDB時觀察到的最常見的設(shè)置，允許在不關(guān)閉整個系統(tǒng)的情況下輪換升級TSD。
HBase有許多可以調(diào)整的參數(shù)，一般而言，大多數(shù)OpenTSDB的瓶頸都來自HBase。確保監(jiān)視服務(wù)器，特別是隊列，緩存，響應(yīng)時間，CPU和GC。
沒有數(shù)據(jù)庫系統(tǒng)可以避免長時間運行或資源浪費查詢。要求用戶從較小的時間范圍開始，如1小時，并逐漸增加時間范圍。還有幫助用戶了解基數(shù)，以及如何請求high_cardinality_tag_key=*可能是一個壞主意。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
