一.线上有一台服务器cpu一直跑满,最终定位导是elasticsearch导致的 二.通过一波查找更改jvm和删除 修改后没有生效笔记尴尬 然后网友说删除索引试了试就可以了  哈哈 curl http://localhost:9200/_cat/indices?v 然后删除之前的索引,保留今年的索引 curl -XDELETE http://localhost:9200/索引名字 #然后重启es 发下cpu降低了

公司最近使用ElasticSearch作为数据报表汇总引擎.上线三个月累计数据800万,但是今天突然大面积出现查询超时,上服务器查看服务运行情况,发现cpu使用率高达300% mem 使用率也到了90%,下面记录了整个排查问题的过程 1.首先查看elastic cpu和mem占用情况 //首先查看所有进程 # top //找到对应的elasticserch运行的PID,查看占用内存比较高的线程,Ctrl+c 退出 #top -Hp 12345 //为了下面方便调用API,将elasticsear

最近项目中遇到一个令人头疼的问题,毕竟因为工作需要刚学elasticsearch,也没有去关注elasticsearch的配置问题,安装好默认把它当做数据库一样去使用,这导致接下来的项目直接挂掉...... 当做压力测试的时候,也就五十个请求url,项目突然莫名其妙挂掉...这个不知道什么原因.去服务器查看进程,发现elasticsearch的CPU占有率达到接近50%(这里指哪怕我停掉了相关的服务),甚至偶尔飙升更高,对于部署不少项目的服务器...这就是灾难级别的 后来查看elasticsea

参考:http://zoufeng.net/2018/07/16/cpu-of-elasticsearch-high-search-slow/ elasticsearch主机CPU居高不下100%左右并且一直维持高CPU利用水平 修改配置文件 /etc/elasticsearch/jvm.options -Xms1g -Xmx1g 改成 -Xms4g -Xmx4g 代表启动使用的内存,可以修改,但是不能超过本机最大内存,建议不超过32G 重启elasticsearch即可 CPU利用率下降了

硬盘对集群非常重要,特别是建索引多的情况.磁盘是一个服务器最慢的系统,对于写比较重的集群,磁盘很容易成为集群的瓶颈. 如果可以承担的器SSD盘,最好使用SSD盘.如果使用SSD,最好调整I/O调度算法.RAID0是加快速度的不错方法. ES建议机器配置:64G内存 SSD硬盘 RAID0,不要使用NAS. 自动调整存储带宽 在2.0.0之前,elasticsearch会限制合并速度(merges),默认为20MB/sec.但是这个速率经常是显得太小,导致合并速度落后于索引速度,进而限制了索引速度

在使用中我们把文档存入ElasticSearch,但是如果能够了解ElasticSearch内部是如何存储的,将会对我们学习ElasticSearch有很清晰的认识.本文中的所使用的ElasticSearch集群环境,可以通过查看ElasticSearch 5学习(3)--单台服务器部署多个节点搭建学习. ElasticSearch用于构建高可用和可扩展的系统.扩展的方式可以是购买更好的服务器(纵向扩展(vertical scale or scaling up))或者购买更多的服务器(横向扩展(

Elasticsearch对Java虚拟机进行了预先的配置.通常情况下,因为这些配置的选择还是很谨慎的,所以你不需要太关心,并且你能立刻使用ElasticSearch. 但是,当你监视ElasticSearch节点内存时,你可能尝试修改一些配置.这些修改是否会改善你的处境? 这篇博文尝试揭开Elasticsearch配置的神秘面纱,并且讨论最常见的调整.最终,会给出一些推荐的配置调整. Elasticsearch JVM 配置概览: 这些是Elasticsearch 0.19.11版本的默认配置

一个Elasticsearch节点会有多个线程池,但重要的是下面四个: 索引(index):主要是索引数据和删除数据操作(默认是cached类型) 搜索(search):主要是获取,统计和搜索操作(默认是cached类型) 批量操作(bulk):主要是对索引的批量操作(默认是cached类型) 更新(refresh):主要是更新操作(默认是cached类型) 可以通过给设置一个参数来改变线程池的类型(type),例如,把索引的线程池改成blocking类型: threadpool: index:

How To Elasticsearch默认是提供了一个非常简单的即开即用体验.用户无需修改什么配置就可以直接使用全文检索.结果高亮.聚合.索引功能. 但是想在项目中使用高性能的Elasticsearch,有几方面优化方法最好掌握. 本文就是为了引导如何优化. 常规建议 不要一次返回太大量的搜索结果集 Elasticsearch设计作为一个搜索引擎,非常擅长返回匹配的查询结果.但是,它并不合适像数据库一样,把整个document作为查询结果返回.如果非要这样做,最好还是使用Scroll这个接口来

1.内存优化 在bin/elasticsearch.in.sh中进行配置 修改配置项为尽量大的内存: ES_MIN_MEM=8g ES_MAX_MEM=8g 两者最好改成一样的,否则容易引发长时间GC(stop-the-world) elasticsearch默认使用的GC是CMS GC,如果你的内存大小超过6G,CMS是不给力的,容易出现stop-the-world,建议使用G1 GC JAVA_OPTS=”$JAVA_OPTS -XX:+UseParNewGC” JAVA_OPTS=”$JA

一.介绍 1. Fluentd 是一个开源收集事件和日志系统,用与各node节点日志数据的收集.处理等等.详细介绍移步-->官方地址:http://fluentd.org/ 2. Elasticsearch 是一个开源的,基于Lucene的搜索服务器.它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口.详细介绍移步-->官方地址:http://www.elasticsearch.org/overview/ 3. Kibana 开源的用于数据可视化的web ui工具,可使

简介 概念 安装部署 ES安装 数据索引 索引优化 内存优化 1简介 ElasticSearch(简称ES)是一个分布式.Restful的搜索及分析服务器,设计用于分布式计算:能够达到实时搜索,稳定,可靠,快速.和Apache Solr一样,它也是基于Lucence的索引服务器,而ElasticSearch对比Solr的优点在于: 轻量级:安装启动方便,下载文件之后一条命令就可以启动. Schema free:可以向服务器提交任意结构的JSON对象,Solr中使用schema.xml指定了索引结

ES 手册 如何提高ES的性能 不要返回较大的结果集 ES是设计成一个搜索引擎的,只擅长返回匹配查询较少文档,如果需要返回非常多的文档需要使用Scroll. 避免稀疏 因为ES是基于Lucene来索引和存储数据的,所以对稠密的数据更有效.Lucene能够有效的确定文档是通过一个整数的文档id,无论有没有数据都会话费一个字节存储id.稀疏主要影响norms和doc_values,一些可以避免稀疏的推荐: 避免将不相关的数据放到相同的索引中 规范的文档结构 使用相同的字段名来保存同样的数据. 避免类

集群 补充章节 正如前文提到的,这就是第个补充的章节,这里会介绍 Elasticsearch 如何在分布式环境中运行. 本章解释了常用术语,比如 集群 (cluster), 节点 (node) 以及 分片 (shard),以及如何横向扩展主机,如何处理硬件故障. 尽管这一章不是必读章节 —— 你可以完全不用理会分片,复制以及故障恢复就能长时间使用 Elasticsearch.你可以先跳过这一章节,然后在你需要的时候再回来. 你可以随时根据你的需要扩展 Elasticsearch.你可以购买配置更

Elasticsearch 的基本信息大致如图所示,这里就不具体介绍了. 本次分享主要包含两个方面的实战经验:索引性能和查询性能. 一. 索引性能(Index Performance) 首先要考虑的是,索引性能是否有必要做优化? 索引速度提高与否?主要是看瓶颈在什么地方,若是 Read DB(产生DOC)的速度比较慢,那瓶颈不在 ElasticSearch 时,优化就没那么大的动力.实际上 Elasticsearch 的索引速度还是非常快的. 我们有一次遇到 Elasticsearch 升级后索

搭建该平台的目的就是为了运维.研发很方便的进行日志的查询.Kibana一个免费的web壳:Logstash集成各种收集日志插件,还是一个比较优秀的正则切割日志工具:Elasticsearch一个开源的搜索引擎框架(支持群集架构方式). 1 安装需求 1.1 理论拓扑 1.2 安装环境 1.2.1 硬件环境 192.168.50.62(HP DL 385 G7 .RAM:12G.CPU:AMD 6128.DISK:SAS 146*4) 192.168.50.98(HP DL 385 G7 .RAM

ES 手册 如何提高ES的性能 不要返回较大的结果集 ES是设计成一个搜索引擎的,只擅长返回匹配查询较少文档,如果需要返回非常多的文档需要使用Scroll. 避免稀疏 因为ES是基于Lucene来索引和存储数据的,所以对稠密的数据更有效.Lucene能够有效的确定文档是通过一个整数的文档id,无论有没有数据都会话费一个字节存储id.稀疏主要影响norms和doc_values,一些可以避免稀疏的推荐: 避免将不相关的数据放到相同的索引中 规范的文档结构 使用相同的字段名来保存同样的数据. 避免类

elasticsearch性能调优 集群规划 独立的master节点,不存储数据, 数量不少于2 数据节点(Data Node) 查询节点(Query Node),起到负载均衡的作用 Linux系统参数配置 文件句柄 Linux中,每个进程默认打开的最大文件句柄数是1000,对于服务器进程来说,显然太小,通过修改/etc/security/limits.conf来增大打开最大句柄数 * - nofile 65535 虚拟内存设置 max_map_count定义了进程能拥有的最多内存区域 sysc

规划一个可用于生产环境的elasticsearch集群. 集群节点划分 整个集群的节点分为以下三种主要类型 Master nodes -- 负责维护集群状态,不保存index数据, 硬件要求: 一般性的机器就可以,给es进程分配16g内存 Data Nodes -- 只保存index的数据,不被选举为Master nodes 硬件要求: 配置要求越高越好,使用大硬盘,有条件可以上SSD硬盘 Client Nodes -- 主要用于负载均衡,不被选举为Master node, 也不保存index数

1.ES大量做FULL GC,日志如下: [2016-12-15 14:53:21,496][WARN ][monitor.jvm ] [vsp4] [gc][old][94725][4389] duration [26.9s], collections [1]/[27s], total [26.9s]/[15.9h], memory [19.7gb]->[17gb]/[19.8gb], all_pools {[young] [1.1gb]->[43.1mb]/[1.1gb]}{[surviv