国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

淺談某運維平臺ES優化之路

IT那活兒 / 3355人閱讀
淺談某運維平臺ES優化之路
點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

  
近期的某一天凌晨三點我收到一條ES異常告警，登錄環境發現ES節點數在正常和異常間反復橫跳，查看日志發現數據節點與master節點通信異常，出現數據節點頻繁上下線的情況，ES集群壓力山大，處理恢復后續又多次出現了該問題，ES優化刻不容緩，以下我就此分享下ES的優化方案。





優化方案



1. 索引分片數優化

首先我們先看一下ES集群的整體情況，ES共24個節點，其中6個master節點，18個data節點，數據量11.9TB，但是索引數達到了12817，分片數量達到了53617，了解ES的同學肯定知道，這樣的分片數肯定是遠超了官方建議的。
我們先看看為什么會有這么多索引和分片數，索引設置是否合理。
以索引domp_10000_zhuji-messages為例，可見索引分片數為1，副本數為1，數據量最大的不過10M，一般來說日志類的索引一個分片可以承載30G左右的數據，可見domp_10000_zhuji-messages這樣數據量的索引完全沒有必要做日索引。
與應用溝通得知索引domp_10000_zhuji-messages保留周期為90天，意味著domp_10000_zhuji-messages索引就能占180個分片，如果我們將其改造為月索引，單個索引數據量預估在300M左右，一個分片也是完全夠用，那么此時在保留周期內我們只需要6個分片就可以滿足需求，分片數量直接減少了30倍。
應用到整個集群，索引數和分片數量將大幅度的減少，從而可減輕ES集群不小的壓力。
2. 減少監控采集頻率
查看日志會發現ES監控索引數據寫入被拒絕，監控這塊的寫入比較大。
查看監控索引大小，居然能達到40G以上，這對ES的壓力可想而知還是比較大的。
ES默認的采集頻率為10S，我們將調整采集頻率調整為60S，減少監控對ES產生的壓力。
curl  -u elastic:elastic -H Content-Type: application/json -XPUT 
http://XXX.XXX.XXX.101:9206/_cluster/settings  -d {"persistent": {"xpack.monitoring.collection.interval":"60s"}}
ES在7.0后需要在kibana.yml配置文件中加入xpack.monitoring.min_interval_seconds參數，需與ES集群配置的采集頻率相同，加了之后可別忘了重啟kibana。
必要的話也可以放棄對索引的監控，只收集集群元數據，調整參數xpack.monitoring.collection.indices":".*"，指定需要監控的索引，默認是監控所有索引。





查詢優化



ES集群壓力如此之大，當時在跑什么查詢？
我們可以通過查看慢查詢日志，查看當時的查詢情況。
/*
慢查詢日志添加方式,時間級別可根據實際情況而定。
PUT _all/_settings {
"index.indexing.slowlog.threshold.index.warn": "10s",
"index.indexing.slowlog.threshold.index.info": "5s",
"index.indexing.slowlog.threshold.index.debug": "2s",
"index.indexing.slowlog.threshold.index.trace": "500ms",
"index.indexing.slowlog.level": "info",
"index.indexing.slowlog.source": "true"
}
**/
通過慢日志，我們可以發現當時主要語句為:
以上查詢使用用了ES中的in查詢，in中id數量遠超1024，默認情況下參數indices.query.bool.max_clause_count值為1024，此參數限制大查詢占用過多的CPU和內存，此查詢遠超此限制將占用大量的CPU和內存資源。
整改方法：采用循環查詢，一次取100個id的 數據，經測試查詢總耗時與原方法無較大差異，資源消耗卻大大減少。
并且針對大索引的查詢，應用程序之前是使用from-size，from-size的工作原理是：如size=10&from=100，那么ElasticSearch會從每個Shard里取出100條數據，然后再排序，取出前10條。
由此觀之，當索引非常大時，from-size查詢對集群的壓力會特別高，相對于from和size的分頁來說，使用scroll可以模擬一個傳統數據的游標，記錄當前讀取的文檔信息位置。所以scroll查詢能大大降低集群的壓力。

本文作者：劉 能（上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129401.html

相關文章

  • 樂心醫療的 Kubernetes云平臺建設實踐

    摘要：宋體自年被開源以來，很快便成為了容器編排領域的標準。宋體年月，樂心醫療的第一個生產用集群正式上線。所以于年推出后，樂心醫療的運維團隊在開會討論之后一致決定盡快遷移到。Kubernetes 自 2014 年被 Google 開源以來，很快便成為了容器編排領域的標準。因其支持自動化部署、大規模可伸縮和容器化管理等天然優勢，已經被廣泛接納。但由于 Kubernetes 本身的復雜性，也讓很多企業的...

    testHs 評論0 收藏0

  • 某熊的技術之路指北 ?

    某熊的技術之路指北 ? 當我們站在技術之路的原點，未來可能充滿了迷茫，也存在著很多不同的可能；我們可能成為 Web/(大)前端/終端工程師、服務端架構工程師、測試/運維/安全工程師等質量保障、可用性保障相關的工程師、大數據/云計算/虛擬化工程師、算法工程師、產品經理等等某個或者某幾個角色。某熊的技術之路系列文章/書籍/視頻/代碼即是筆者蹣跚行進于這條路上的點滴印記，包含了筆者作為程序員的技術視野、...

    shadowbook 評論0 收藏0

  • 前端資源收集整理

    摘要：工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 Github版本：Front-End Resource Collection 前端相關資源匯總 學習指導 精華文章 Web前端的路該怎么走？：文章超長，但是干貨超級多，值得反復精讀！ 聽說2017你想寫前端？：適合于已經度過了小白階...

    awesome23 評論0 收藏0

  • 前端資源收集整理

    摘要：工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 Github版本：Front-End Resource Collection 前端相關資源匯總 學習指導 精華文章 Web前端的路該怎么走？：文章超長，但是干貨超級多，值得反復精讀！ 聽說2017你想寫前端？：適合于已經度過了小白階...

    antyiwei 評論0 收藏0

  • 前端資源收集整理

    摘要：工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 工作原因，最近一年斷斷續續寫了一點前端代碼，收集整理了一些資料，和大家共享。 Github版本：Front-End Resource Collection 前端相關資源匯總 學習指導 精華文章 Web前端的路該怎么走？：文章超長，但是干貨超級多，值得反復精讀！ 聽說2017你想寫前端？：適合于已經度過了小白階...

    KavenFan 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<