elasticsearch常见问题
使用es还是有很多注意事项的,就在这里慢慢总结吧。
操作系统部分
- 在centos7.5里默认的io调度策略是mq-deadline,需要改为none,不过看了下各种评测,这2个的差距其实是相当小的。现在最好的应该是BFQ low_latency。 https://www.phoronix.com/scan.php?page=article&item=linux417-nvme-io&num=2 但这个是到4.17内核里了。
- 磁盘挂载, noatime:不记录文件访问时间戳。nodiratime:不记录目录访问时间戳。data=writeback:不记录data journal,提高文件系统写入性能。barrier=0:barrier保证journal先于data刷到磁盘,前面关闭了journal,这里的barrier也就没必要开启了。nobh:关闭buffer_head,防止内核打断大块数据的IO操作。
/etc/fstab
Created by anaconda on Fri Jun 2 07:36:28 2017
Accessible filesystems, by reference, are maintained under ‘/dev/disk’
See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/data/es /data ext4 noatime,nodiratime,data=writeback,barrier=0,nobh 0 0
es本身
现在es的磁盘已经很大了,默认水位线是75%,但是这样的话就不会分配新的shard到这个机器上了,这很浪费空间。这里也可以写绝对值,比如100G什么的
1 | curl -XPUT http://es-master1:9200/_cluster/settings -d ' |
对于有些只是存放日志的es,可以把刷新的频率降低
1 | "settings": { |
和kibana相关
Kibana 中的以下错误:“Courier fetch: n of m shards failed (Courier 提取: n 个 (共 m 个) 分片失败)”?
下面这个是在aws上的问题和解释
当我尝试在我 Kibana 中加载控制面板时,返回以下错误:“Courier fetch: n of m shards failed (Courier 提取: n 个 (共 m 个) 分片失败)”。示例: Error: Courier Fetch: 5 of 60 shards failed 注意:导致出现此错误的原因有多个。此处讨论了四种常见解决方法。 简短描述 接收来自客户端的搜索请求的集群节点将协调跨多个相关节点的查询执行。如果协调节点发送的请求在收到来自所有相关分片的响应之前超时,则会出现 Courier 提取错误。有关更多信息,请参阅 Elasticsearch 文档中的查询阶段和提取阶段。
一开始都是沿着这个思路来的,结果看了下es的日志,发现有报错
Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: parse_exception: Cannot parse 'message:"xxxxxxxx-daa2-4645-a39e-yyyyyy" AND message:"postGeneralForAnswer“': Lexical error at line 1, column 82. Encountered:after : "\"postGeneralForAnswer\u201c"
原来是某人查的时候,后面的双引号弄错了,可为什么kibana是报这个错呢?