1. 程式人生 > >探究 | Elasticsearch CPU高排查思路

探究 | Elasticsearch CPU高排查思路

一、可能導致ES CPU高的原因:

1、複雜的query查詢

舉例:我這邊出現過200個組合wildcard query導致叢集down掉的情況;

2、有大量的reindex操作

3、ES版本較低

二、排查思路

2.1、業務場景排查

問自己幾個問題?
- 1)叢集中資料型別是怎麼樣的?
- 2)叢集中有多少資料?
- 3)叢集中有多少節點數、分片數?
- 4)當前叢集索引和檢索的速率如何?
- 5)當前在執行哪種型別的查詢或者其他操作?

2、建議Htop觀察,結合ElaticHQ 觀察CPU曲線

3、CPU高的時候,建議看一下ES節點的日誌,看看是不是有大量的GC。

4、檢視hot_threads。

GET _nodes/hot_threads

::: {test}{ikKuXkFvRc-qFCqG99smGg}{VE-uqoiARoONJwomfPwRBw}{127.0.0.1}{127.0.0.1:9300}{ml.machine_memory=8481566720, ml.max_open_jobs=20, ml.enabled=true}
   Hot threads at 2018-04-09T15:58:21.117Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

    0.0% (0s out of 500
ms) cpu usage by thread 'Attach Listener' unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot unique snapshot

三、解決方案:

3.1、叢集負載高,增加新節點以緩解負載。

3.2、增加堆記憶體到系統記憶體的1半,最大31GB(理論上線32GB).

3.3、插入資料的時候,副本數設定為0.

分片數不可以修改,副本數是可以修改的。

注意:分片過多,會導致:堆記憶體壓力大。

3.4、配置優化

Force all memory to be locked, forcing the JVM to never swap
bootstrap.mlockall: true
Threadpool Settings
Search pool
threadpool.search.type: fixed
threadpool.search.size: 20
threadpool.search.queue_size: 200
Bulk pool
threadpool.bulk.type: fixed
threadpool.bulk.size: 60
threadpool.bulk.queue_size: 3000
Index pool
threadpool.index.type: fixed
threadpool.index.size: 20
threadpool.index.queue_size: 1000
Indices settings
indices.memory.index_buffer_size: 30%
indices.memory.min_shard_index_buffer_size: 12mb
indices.memory.min_index_buffer_size: 96mb
Cache Sizes
indices.fielddata.cache.size: 30%
#indices.fielddata.cache.expire: 6h #will be depreciated & Dev recomend not to use it
indices.cache.filter.size: 30%
#indices.cache.filter.expire: 6h #will be depreciated & Dev recomend not to use it
Indexing Settings for Writes
index.refresh_interval: 30s
#index.translog.flush_threshold_ops: 50000
#index.translog.flush_threshold_size: 1024mb
index.translog.flush_threshold_period: 5m
index.merge.scheduler.max_thread_count: 1

2018年04月10日 0:18於家中床前

image)

相關推薦

探究 | Elasticsearch CPU排查思路

一、可能導致ES CPU高的原因: 1、複雜的query查詢 舉例:我這邊出現過200個組合wildcard query導致叢集down掉的情況; 2、有大量的reindex操作 3、ES版本較低 二、排查思路 2.1、業務場景排查

壓力測試過程中MySQL服務CPU占用率過的問題排查思路

建立索引 效果 mysql服務器 還要 數據庫服務 如果 頻率 water vpd 〇、經驗總結: 在關註業務接口的TPS時,也要關註數據庫服務器的QPS。如果一個業務流程裏包含多條查詢,那麽業務接口TPS的上升對數據庫服務器QPS的放大效應會很明顯。 如果查詢結果集不大

雲伺服器 ECS Linux 系統 CPU 佔用率較問題排查思路

如果雲伺服器 ECS Linux 系統的 CPU 持續跑高,則會對系統穩定性和業務執行造成影響。本文對 CPU 佔用率較高問題的排查分析做簡要說明。可以通過 vmstat 從系統維度檢視 CPU 資源的使用情況。用法說明:格式:vmstat -n 1-n 1表示結果一秒重新整理一次。示例輸出:$ vmstat

Linux 系統 CPU 佔用率較問題排查思路

CPU負載檢視方法: 使用vmstat檢視系統維度的CPU負載 使用top檢視程序維度的CPU負載 使用 vmstat 檢視系統緯度的 CPU 負載: 可以通過 vmstat 從系統維度檢視 CPU 資源的使用情況。 用法說明: 格式:vmstat -n 1# -n 1

MySql CPU到百分之1000的排查思路

You need to enable JavaScript to run this app.   原文內容來自於LZ(樓主)的印象筆記,如出現排版異常或圖片丟失等情況,可檢視當前連結:https://app.yinxiang.com/fx/bf7839b3-5f7b-4212-9f

Java進程CPU使用率排查

java進程cpu使用率高排查生產java應用,CPU使用率一直很高,經常達到100%,通過以下步驟完美解決,分享一下。1.jps 獲取Java進程的PID。2.jstack pid >> java.txt 導出CPU占用高進程的線程棧。3.top -H -p PID 查看對應進程的哪個線程占用C

TPS低,CPU--記一次storm壓測問題排查過程

進入 狀態 其他 value 由於 均衡 線程狀態 左右 grep 命令 一、業務背景+系統架構 本次場景為kafka+storm+redis+hbase,通過kafka的數據,進入storm的spout組件接收,轉由storm的Bolt節點進行業務邏輯處

elasticsearch CPU原因查找

elasticsearch CPU 今天稍微壓了了一下線上的ES集群,發現CPU 過高,線上用的是4核16G。 找到ES的進程14642, 執行 top -Hp 14642 選取其中一個過高的線程 jstack 14642 | grep -A 30 3989 發現 你也可以用 jstack 14

cpu佔用過排查

top命令是Linux下常用的效能分析工具,能夠實時顯示系統中各個程序的資源佔用狀況,類似於Windows的工作管理員 內容解釋: PID:程序的ID USER:程序所有者 PR:程序的優先級別,越小越優先被執行 NInice:值 VIRT:程序佔用的虛擬記憶體 RES:程序佔用的實體記憶體 SHR:程

linux程序和執行緒排查 · 記一次JVM CPU負載的排查辦法

前言通過本文,你將學會:1、linux上程序及程序中執行緒排查的基本方法,如檢視程序中的執行緒數此文中的執行緒一般指輕量級程序。檢視所有程序資訊 top -H 加上-H這個選項啟動top,top一行顯示一個執行緒(指的是(輕量級)程序? )。否則,它一行顯示一個程序。先輸入

jvm cpu排查實戰

雙十一了,頭一天晚上10點左右收到阿里雲cpu超過90%簡訊報警。 第二天上班了,開始處理,步驟如下: 1、top找出cpu高的java程序號9592 2、top -Hp  9592檢視cpu佔用time最高的執行緒編號28178 3、執行 printf "%x\n" 28

系統執行緩慢,CPU 100%,以及Full GC次數過多問題的排查思路及解決方案

浪費了“黃金五年”的Java程式設計師,還有救嗎? >>>   

系統運行緩慢,CPU 100%,以及Full GC次數過多問題的排查思路

底部 力度 users nts java程序 來源 $$ 不定 進程 前言 處理過線上問題的同學基本上都會遇到系統突然運行緩慢,CPU 100%,以及Full GC次數過多的問題。當然,這些問題的最終導致的直觀現象就是系統運行緩慢,並且有大量的報警。 本文主要針對系統運行緩

再一次生產 CPU 負載排查實踐

前言 前幾日早上開啟郵箱收到一封監控報警郵件:某某 ip 伺服器 CPU 負載較高,請研發儘快排查解決,傳送時間正好是凌晨。 其

一次線上CPU的問題排查實踐

一次線上CPU高的問題排查實踐 前言 近期某一天上班一開電腦,就收到了運維警報,有兩臺服務CPU負載很高,同時收到一線同事反饋 系統訪問速度非常慢,幾乎無響應。 一個美好的早晨,最怕什麼就來什麼。只好推掉其他會議,專心搞定問題。 排查 登入系統一看,後端的介面訪問果然全部超時。 先使用top命令檢視下是由哪

Linux 連接數過多排查思路

div linux netstat tcp連接 linu 占用 nap code 思路 ## 在連接數報警的機器上,查看某個端口tcp連接來源,並排序 netstat -natl |grep ^tcp |grep ":2181" |awk ‘{print $5}‘|awk

tomcat內存占用過排查小結

java tomcat 內存泄漏 假設tomcat進程PID為16818確認是不是內存本身分配過小:jmap -heap 16818找到最耗內存的對象:jmap -histo 16818 (帶上:live則表示先進行一次FGC再統計,如jmap -histo:live 16818)導出內存轉儲快照

查看進程中占cpu的線程方法

process 工具 微軟 cpu高 線程 轉換 ber stack images 當在任務管理器中發現有進程占用cpu過高的時候通過下面的指令將進程快照導出到c盤 jstack -l 進程PID> c:/進程PID.stack 查看進程PID的方法: 然後我們

RPC服務超時排查思路

log 時間 業務 超時 超時時間 提供者 服務提供者 堆棧 div RPC服務超時排查思路- 1、查看服務提供者日誌相關信息進行排查- 2、查看消費者的超時時間設置是否合理- 3、查看服務提供者業務邏輯是否有DB操作,有的話看是否有慢SQL- 4、查看服務提供者業務邏輯

Linux 某個進程中占用CPU的線程

alt 技術分享 fill size print 當前 AC fontsize java 1、通過top,找出占用CPU高的進程ID 2、 如上圖所示,java的進程id為’52554′,接下來用top命令單獨對這個進程中的所有線程作監視: top-p52554 -H 3