skywalking之elasticsearch cpu高
最近apm项目比较火,作为Apache的顶级项目之一的skywalking线上搭建部署.里面用到了elasticsearch作为存储引擎,作为JAVAEE的我其实对elasticsearch不是很熟,就当睬坑了吧,然后将事情的经过记录下来,希望能帮助到遇到问题的你,当然有问题也可以线下沟通,或者留言.
ES线上集群环境,运行一段时间之后就出现cpu100%的情况.
如图:
此机器cpu是4核,memory 8G
通过性能分析发现是平均每秒发生一次ygc,修改jvm的gc策略后无果.
只能先通过升级配置,
cpu 4核—>8核
memory 8G—>16G
后续修改,jvm配置如下:
运行几个小时之后发现cpu又变高了.然后google,修改elasticsearch.yml
index.merge.scheduler.max_thread_count: 1 # 索引 merge 最大线程数
indices.memory.index_buffer_size: 30% # 内存
index.translog.durability: async # 这个可以异步写硬盘，增大写的速度
index.translog.sync_interval: 120s #translog 间隔时间
discovery.zen.ping_timeout: 120s # 心跳超时时间
discovery.zen.fd.ping_interval: 120s # 节点检测时间
discovery.zen.fd.ping_timeout: 120s #ping 超时时间
discovery.zen.fd.ping_retries: 6 # 心跳重试次数
thread_pool.bulk.size: 20 # 写入线程个数 由于我们查询线程都是在代码里设定好的，我这里只调节了写入的线程数
thread_pool.bulk.queue_size: 1000 # 写入线程队列大小
index.refresh_interval: 300s #index 刷新间隔
重启之后发现elasticsearch6.5不支持对index级别的设置,给出提示使用
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{
"index.merge.scheduler.max_thread_count" : "1",
"index.refresh_interval" : "30s",
"index.translog.durability" : "async",
"index.translog.sync_interval" : "120s"
}'
然后修改对应localhost执行提示:
Can't update non dynamic settings
然后继续google,
https://stackoverflow.com/questions/19758335/error-when-trying-to-update-the-settings
显示需要先close索引,然后再执行,最后成功之后再打开
curl -XPOST 'http://localhost:9200/_all/_close'
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{
"index.merge.scheduler.max_thread_count" : "1",
"index.refresh_interval" : "30s",
"index.translog.durability" : "async",
"index.translog.sync_interval" : "120s"
}'
curl -XPOST 'http://localhost:9200/_all/_open'
运行几个小时继续截图
settings.index.merge.scheduler.max_thread_count
合并调度程序（ConcurrentMergeScheduler）在需要时控制合并操作的执行（根据合并策略）。
default:
Math.max(1, Math.min(3, Runtime.getRuntime().availableProcessors() / 2))
index refresh_interval: 设置成30s
因为刷新很昂贵，所以提高索引吞吐量的一种方法是增加refresh_interval。较少刷新意味着负载较少，并且可以将更多资源转移到索引线程。
持续关注cpu问题