ElasticSearch知识图谱

初始状态

副本分片分配

分片平均分配

是不是效率有些低？这种询问量=shard数×
节点数。所以说我们最好控制shard的总规模别太大。

ES5.x以下的版本，通过对比shard级元信息的版本号来决定。在多副本的情况下，考虑到如
果只有一个shard信息汇报上来，则它一定会被选为主分片，但也许数
据不是最新的，版本号比它大的那个shard所在节点还没启动。

在解决这个问题的时候，ES5.x开始实施一种新的策略：给每个shard都设置一
个UUID，然后在集群级的元信息中记录哪个shard是最新的，因为ES是
先写主分片，再由主分片节点转发请求去写副分片，所以主分片所在节
点肯定是最新的，如果它转发失败了，则要求Master删除那个节点。

所以，从ES5.x开始，主分片选举过程是通过集群级元信息中记录的“最新
主分片的列表”来确定主分片的：汇报信息中存在，并且这个列表中也
存在。

如果集群设置了：＂cluster.routing.allocation.enable＂:＂none＂禁止分配分片，集群仍会强制分配主分片。因此，在设置了上述选项的情况下，集群重启后的状态为Yellow，而非Red。

phase1：在主分片所在节点，获取translog保留锁，从获取保留锁
开始，会保留translog不受其刷盘清空的影响。 然后调用Lucene接口把
shard做快照，这是已经刷磁盘中的分片数据。把这些shard数据复制到
副本节点。在phase1完毕前，会向副分片节点发送告知对方启动
engine，在phase2开始之前，副分片就可以正常处理写请求了。

phase2：对translog做快照，这个快照里包含从phase1开始，到执
行translog快照期间的新增索引。将这些translog发送到副分片所在节点
进行重放。

·检查Lucene版本，ES各版本对使用的Lucene版本是有要求的，在这里检查Lucene版本以防止有人替换不兼容的jar包。

·检测jar冲突（JarHell），发现冲突则退出进程。

在早期的ES版本中，ES检测到一些不合理的配置会记录到日志中继续运行。但是有时候用户会错过这些日志。为了避免后期才发现问题，ES在启动阶段对那些很重要的参数做检查，一些影响性能的配置会被标记为错误，让用户足够重视这些参数。

所有这些检查被单独封装在BootstrapChecks类中。目前有下面这些
检测项

节点关闭过程中，IndicesService的doStop对Engine设置了超时，如
果flushAndClose一直等待，则CountDownLatch.await默认1天才会继续后
面的流程。

Leader选举的基本算法之一。

它假定所有节点都有一个唯一的ID，
使用该ID对节点进行排序。任何时候的当前Leader都是参与集群的最高
ID节点。该算法的优点是易于实现。

但是，当拥有最大ID的节点处于不
稳定状态的场景下会有问题。例如，Master负载过重而假死，集群拥有
第二大ID的节点被选为新主，这时原来的Master恢复，再次被选为新
主，然后又假死……

ES通过推迟选举，直到当前的Master失效来解决上述问题，只要
当前主节点不挂掉，就不重新选主。但是容易产生脑裂（双主），为
此，再通过“法定得票人数过半”解决脑裂问题。

Paxos非常强大，尤其在什么时机，以及如何进行选举方面的灵活
性比简单的Bully算法有很大的优势，因为在现实生活中，存在比网络
连接异常更多的故障模式。

但 Paxos 实现起来非常复杂。

最大线程数max_thread_count的默认值如下：
Math.max（1,Math.min（4,Runtime.getRuntime（）.availableProcessors（）/2））
以上是一个比较理想的值，如果只有一块硬盘并且非SSD，则应该
把它设置为1，因为在旋转存储介质上并发写，由于寻址的原因，只会
降低写入速度。

merge策略index.merge.policy有三种：
·tiered（默认策略）；
·log_byete_size；
·log_doc。

建立索引的过程属于计算密集型任务，应该使用固定大小的线程池
配置，来不及处理的任务放入队列。线程池最大线程数量应配置为CPU
核心数+1，这也是bulk线程池的默认设置，可以避免过多的上下文切
换。队列大小可以适当增加，但一定要严格控制大小，过大的队列导致
较高的GC压力，并可能导致FGC频繁发生。

bulk写请求是个长任务，为了给系统增加足够的写入压力，写入过
程应该多个客户端、多线程地并行执行，如果要验证系统的极限写入能
力，那么目标就是把CPU压满。

磁盘util、内存等一般都不是瓶颈。如
果CPU没有压满，则应该提高写入端的并发数量。

但是要注意bulk线程池队列的reject情况，出现reject代表ES的bulk队列已满，客户端请求
被拒绝，此时客户端会收到429错误（TOO_MANY_REQUESTS），客
户端对此的处理策略应该是延迟重试。不可忽略这个异常，否则写入系
统的数据会少于预期。

即使客户端正确处理了429错误，我们仍然应该尽量避免产生reject。因此，在评估极限的写入能力时，客户端的极限写入并发量应该控制在不产生reject前提下的最大值为宜。

index：控制字段值是否被索引。它可以设置为true或false，默认
为true。未被索引的字段不会被查询到，但是可以聚合。除非禁用
doc_values

docvalues：默认情况下，大多数字段都被索引，这使得它们可以
搜索。倒排索引根据term找到文档列表，然后获取文档原始内容。但是
排序和聚合，以及从脚本中访问某个字段值，需要不同的数据访问模
式，它们不仅需要根据term找到文档，还要获取文档中字段的值。这些
值需要单独存储。doc_values就是用来存储这些字段值的。

它是一种存储在磁盘上的列式存储，在文档索引时构建，这使得上述数据访问模式
成为可能。它们以面向列的方式存储与_source相同的值，这使得排序和
聚合效率更高。几乎所有字段类型都支持doc_values，但被分析
（analyzed）的字符串字段除外（即text类型字符串）。doc_values默认
启用。

store：默认情况下，字段值会被索引使它们能搜索，但它们不会
被存储（stored）。意味着可以通过这个字段查询，但不能取回它的原
始值

在text类型的字段上，index_options的默认值为positions。
index_options参数用于控制添加到倒排索引中的信息。

freqs文档编号和词频被索引，词频用于为搜索评分，重复出现的
词条比只出现一次的词条评分更高。positions文档编号、词频和位置被
索引。位置被用于邻近查询（proximityqueries）和短语查询（phrase
queries）。
完整的index_options选项请参考官方手册：
https://www.elastic.co/guide/en/elasticsearch/reference/master/index-
options.html

子主题

设置

下例将字符串字段映射为keyword：

PUTindex
{
＂settings＂:{
＂index＂:{
＂codec＂:＂best_compression＂
}
}
}

（1）部署单个节点，JVM内存配置不超过32GB，配置全部数据
盘。这种部署模式的缺点是多余的物理内存只能被cache使用，而且只
要存在一个坏盘，节点重启会无法启动。

（2）部署单个节点，JVM内存配置超过32GB，配置全部数据盘。
接受指针压缩失效和更长时间的GC等负面影响。

（3）有多少个数据盘就部署多少个节点，每个节点配置单个数据
路径。优点是可以统一配置，缺点是节点数较多，集群管理负担大，只
适用于集群规模较小的场景。

（4）使用内存大小除以64GB来确定要部署的节点数，每个节点配
置一部分数据盘，优点是利用率最高，缺点是部署复杂

PUT_cluster/settings
{
＂transient＂:{
＂cluster.routing.allocation.exclude._name＂:＂node-1＂
}
}
执行命令后，分片开始迁移，我们可以通过_cat/shardAPI来查看该
节点的分片是否迁移完毕。

当节点维护完毕，重新上线之后，需要取消
排除设置，以便后续的分片可以分配到node-1节点上。
PUT_cluster/settings
{
＂transient＂:{
＂cluster.routing.allocation.exclude._name＂:＂＂
}
}
完整的分配过滤器使用方式请参考官方手册：
https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-
filtering.html

调节内核参数可以通过两种方式：
（1）临时设置，系统重启后失效。通过sysctl-w来设置，例如：
sysctl-wnet.ipv4.tcp_timestamps=1，命令执行后该参数立即生效。
（2）永久设置，将参数写入配置文件/etc/sysctl.conf，然后执行
sysctl-p使其生效。
可以通过sysctl-A配合grep查看某个参数的当前值。

1.TCP相关参数

2.TCP的接收窗口（RWND）

3.TCP的拥塞窗口（CWND）

4.vm相关参数

5．禁用透明大页（TransparentHugepages）

例如：
{
＂template＂:＂*＂，
＂order＂:0，
＂settings＂:{
＂index.number_of_replicas＂:＂1＂，
＂index.number_of_shards＂:＂24＂
}
}

我们先创建模板，在模板中描述该索引的设置和mapping信息：

- 单一的分段比众多分段占用的磁盘空间更小一些；
·可以大幅减少进程需要打开的文件fd；
·可以加快搜索过程，因为搜索需要检索全部分段；
·单个分段加载到内存时也比多个分段更节省内存占用；
·可以加快索引恢复速度。

例如，按日期轮询生成的索引，可能有些日子里数据量并不大，对这种索
引可以执行Shrink操作来降低索引分片数量。

写入下列测试数据：
POST/user_info/_bulk
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂1＂}}
{＂name＂:＂高X＂}
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂2＂}}
{＂name＂:＂高XX＂}
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂3＂}}
{＂name＂:＂X高X＂}
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂4＂}}
{＂name＂:＂X高X＂}
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂5＂}}
{＂name＂:＂XX高＂}
{＂index＂:{＂_type＂:＂user＂,＂_id＂:＂6＂}}
{＂name＂:＂高XXX＂}

我们期望的返回顺序与两个原则有关：关键词出现的位置越靠前，
排序应该越靠前；字段值约短，说明匹配度越高，排序应该越靠前。
因此，理想的顺序应该是：
高X
高XX
高XXX
X高X
X高X
XX高

下面执行搜索：
GETuser_info/_search?size=20
{
＂query＂:{
＂query_string＂:{
＂query＂:＂（name:（*高*））＂
}
}
}
实际返回结果顺序如下，每一项的得分（_score）都是1.0。
X高X
高XX
X高X
高XXX
高X
XX高

子主题

子主题

子主题

1.Query

2.RewriteTime

3.Collectors

我们创建一个名为test_idx的索引，该索引只有一个主分片，没有
副分片。集群有两个节点，名为A和B。但是在创建索引时，我们设置
分配过滤器，使其不能被分配到节点A和B上 。 PUT/test_idx?wait_for_active_shards=0
{
＂settings＂:
{
＂number_of_shards＂:1，
＂number_of_replicas＂:0，
＂index.routing.allocation.exclude._name＂:＂A,B＂
}
}

虽然索引能创建成功，但是因为过滤规则的限制，索引分片无法分
配到集群仅有的A和B两个节点。此时集群处于Red状态，我们通过
ExplainAPI来获取第一个未分配分片的原因解释（在本例中，集群中只
有一个未分配的分片）。

GET/_cluster/allocation/explain
返回信息摘要如下：

ExplainAPI给出了该分片未分配的原因，由于索引刚创建
（unassigned_info），它处于未分配状态（current_state）。由于没有节
点允许分配给该分片（allocate_explain），所以无法分配分片
（can_allocation）。深入每个节点的决策信息
（node_allocation_decisions），可以看到由于索引的过滤器设置，分配
操作被decider拦截。decider给出了具体的decider名称，接下来是决策结
果及具体的原因（explanation）。

下面更新分配过滤器设置：
PUT/test_idx/_settings
{
＂index.routing.allocation.exclude._name＂:null
}
然后重新运行ExplainAPI，将收到以下结果：
unabletofindanyunassignedshardstoexplain
表示当前没有未分配的分片。我们还可以在主分片上运行Explain
API：
GET/_cluster/allocation/explain
{
＂index＂:＂test_idx＂，
＂shard＂:0，
＂primary＂:true
}
我们可以看到分片被分配到了哪个节点，返回信息摘要如下：
{
＂index＂:＂test_idx＂，
＂shard＂:0，
＂primary＂:true，
＂current_state＂:＂started＂，
＂current_node＂:{
＂id＂:＂tn3qdPdnQWuumLxVVjJJYQ＂，
＂name＂:＂A＂，
＂weight_ranking＂:1
}，
...
}
可以看出分片被成功（started）分配到节点A。
现在，我们向索引test_idx中写入一些数据，然后停掉节点A，由
于该索引没有副分片，所以集群变为Red状态。在主分片上重新运行
ExplainAPI，返回信息摘要如下：
{
＂index＂:＂test_idx＂，
＂shard＂:0，
＂primary＂:true，
＂current_state＂:＂unassigned＂，
＂unassigned_info＂:{
＂reason＂:＂NODE_LEFT＂，
＂details＂:＂node_left[qU98BvbtQu2crqXF2ATFdA]＂，
＂last_allocation_status＂:＂no_valid_shard_copy＂
}，
＂can_allocate＂:＂no_valid_shard_copy＂，
＂allocate_explanation＂:＂cannotallocatebecauseaprevious
copyoftheprimary
shardexistedbutcannolongerbefoundonthenodesin
thecluster＂
}
输出信息告诉我们主分片处于未分配状态（current_state），原因是
持有此分片的节点离线（unassigned_info）。ExplainAPI给出了分片不
能分配的原因，是因为集群中没有任何分片0的有效副本
（can_allocate）。allocate_explanation字段给出了详细的解释。
ExplainAPI告诉我们主分片不再有有效的分片副本，我们知道持
有该分片的节点离线了，此时唯一的办法就是等待节点重新加入集群。
在极端情况下，节点永久移除，只能接受丢失数据的现实，并通过
rerouteAPI重新分配空的主分片。

我们把刚才的索引test_idx副本数调整为1：
PUT/test_idx/_settings
{
＂number_of_replicas＂:1
}
索引test_idx现在有两个分片，分片0的主分片及分片0的副分片。因
为A节点已经存储了主分片，所以副分片将被分配到节点B，以达到集
群均衡的目的。现在在副分片上运行ExplainAPI：
GET/_cluster/allocation/explain
{
＂index＂:＂test_idx＂，
＂shard＂:0，
＂primary＂:false
}
返回信息摘要如下：
{
＂index＂:＂test_idx＂，
＂shard＂:0，
＂primary＂:false，
＂current_state＂:＂started＂，
＂current_node＂:{
＂id＂:＂qNgMCvaCSPi3th0mTcyvKQ＂，
＂name＂:＂B＂，
＂weight_ranking＂:1
}，
…
}

出信息显示分片已经被分配到节点B，并且为started状态。
接下来，我们再次设置索引的分配过滤器，但是这次阻止分配分片
的节点B：
PUT/test_idx/_settings
{
＂index.routing.allocation.exclude._name＂:＂B＂
}

现在重启节点B，在副分片上重新运行ExplainAPI，返回信息摘要
如下：

子主题

结果显示副分片当前处于未分配状态（can_allocate），因为分配过
滤设置了禁止把分片分配到节点B上（explanation）。因为节点A上已经
指派了主分片，所以不允许再把该分片的其他副本分配到A节点
（explanation）。ES会避免将主副分片分配到同一个节点，主要是为了
防止当节点失效时所有副本都不可用，以及可能的数据丢失。

如果分片可以正常分配，为什么还要关注explain信息呢？一个常见
的原因是想将分片手工迁移到某个节点，但是出于某些原因分片没有迁
移，这时ExplainAPI帮助我们展示其中原因

我们清除test_idx索引的过滤器设置，使主副分片都可以正常分配。
PUT/test_idx/_settings
{
＂index.routing.allocation.exclude._name＂:null
}
然后重新设置分配过滤器，使主分片从当前节点迁移走：
PUT/test_idx/_settings
{
＂index.routing.allocation.exclude._name＂:＂A＂
}

我们期望的结果是主分片从节点A移动到另一个节点，然而事与
愿违，在主分片上运行ExplainAPI，看看具体原因：

子主题

从返回结果可以看出，主分片仍然被分配给节点
A（current_node），集群知道这个分片不应该保留在当前节点
（can_remain_on_current_node），原因是主分片被当前节点的decider
拦截（can_remain_decisions）。尽管分片不允许保留在当前节点，但它
也不能移动到其他节点（can_move_to_other_node），因为被节点B的
decider拦截，主副分片不能分配到同一节点。

子主题

iostat是用来分析I/O状态的常用工具，其输出结果是
以/proc/diskstats为基础计算的

例如，我们使用1秒的间隔来采样：
iostat  -xd  1
输出结果包括系统中全部磁盘的信息 . 我们经常关注的几个指标

当I/O产生性能问题时，iostat可能不足以定位故障，可以使用
blktrace来分析I/O请求的各个环节。该工具的原理和使用方式可以参考
http://bean-li.github.io/blktrace-to-report/

进程级I/O状态iostat提供磁盘级的I/O状态，无法关联到进程，如果
想查看哪些进程的I/O最高，则可以使用pidstat或iotop两个工具，它们可
以动态给出每个进程的读写速度。

例如，下面为iotop的输出结果，在统
计信息中给出了全部磁盘的读写速度，以及每个进程的读写速度

如果想看到特定磁盘上特定进程的I/O情况，则这两个工具无法做
到，这种情况可以通过systemtap来监控。

我们感兴趣的是，当系统物理内存不足时，系统回收内存的效率如
何。在这种场景下，我们可以通过sar-B来观察内存分页的统计信息

输出结果中几个字段的含义如下

当一个进程需要更多内存而实际空间不足时，就会发生页面扫描。
内核检查页面，找出哪些页面需要分页（pagedout）。独立地观察
pgscand、pgsteal等数值一般没太多参考意义，除非异常高。通常我们可
以重点关注vmeff的百分比，当值为0或接近100时代表内存够用，当值
比较低时，（例如，低于30%，甚至低于1%）就需要小心，这时页面回
收效率就存在问题。页面回收效率问题可以检查一下内核参数：
vm.zone_reclaim_mode。CentOS7中其默认值为0，当为1的时候，可能
会导致回收效率低下。我们建议确保此值为0，详细内容可参阅NUMA
资料。
关于内存分页的更多信息可以参考维基
Paging:https://en.wikipedia.org/wiki/Paging。

另外一种情况，在开启了交换分区的系统上，可以通过sar-W查看
页面交换情况：
sar-W
09:30:01AMpswpin/spswpout/s
09:40:01AM3.320.00
09:50:01AM13.180.00
10:00:01AM0.540.00
10:10:02AM0.961.3710:20:01AM0.240.00
10:30:01AM0.150.00
10:40:01AM0.850.00
10:50:01AM0.160.00
Average:2.430.17

基本信息vmstat输出用户级（us）和内核级（sy）的CPU占用百分
比，以及采样周期内的上下文切换次数，blockin、blockout次数等信息
如下：
vmstat

mpstat除了获取用户级（usr）和内核级（sys）的CPU占用百分比，
还可以输出采样周期内的软中断（soft）、硬中断（irq）占用时间的百
分比：
mpstat

诊断导致CPU高的系统调用正常情况下应用程序占用用户态CPU时
间，如果进程占用sys比较高，则表示程序执行在内核态的操作非常耗
费CPU，我们可以使用一些工具来检查应用程序产生系统调用的统计信
息。

strace的-c参数可以统计系统调用次数和执行时间。例如：
strace-ooutput.txt-f-c-etrace=all-p5233
strace命令可以指定跟踪哪些类型的系统调用，例如，文件级、进
程相关、网络相关等，也可以跟踪特定的系统调用，例如，open、
close。我们的示例中选择跟踪所有调用。命令执行一段时间后需要手工
按“Ctrl+C”组合键退出，获得以下输出结果：

perf是Linux用户主要的性能分析工具，它可以做的事情很多，现在
我们用它分析CPU。
perf  top用来实时显示系统最耗时的内核函数及进程，动态输出
TopN个结果，如下图所示。

我们还可以使用perf  record来记录函数级别的统计信息，下列命令
对系统采样10秒，并将采样数据输出到cycle.perf文件中。
sudo perf record -a -ecycles -ocycle.perf -g sleep10
接下来，根据采样数据生成报告：
perf report -i cycle.perf|more
输出信息如下：

输出显示87%的时间花在rest_init函数上。
关于perf工具的更多使用方式可以参考IBM的文章：
https://www.ibm.com/developerworks/cn/linux/l-cn-perf1/index.html。Java
也有自己专用的perf工具

sar是用来查看网卡流量的最常用方式，它以字节为单位输出网
络传入和传出流量

子主题

netstat-anp可以列出连接的详细信息，并且可以将连接、监听的端
口对应到进程。其中Recv-Q和Send-Q代表该连接在内核中等待发送和接
收的数据长度，单位为字节。

netstat-s 提供了各个协议下的统计信息，例如，活跃连接数、重传
次数、reset信息等都非常有用。部分输出信息如下所示

netstat是观察网络连接的常用工具，但是在无法处理海量网络连接
的情况下可以用ss代替

ss与netstat功能类似，但适合处理海量连接。

 sudo ss – anp

除了用来查看IP地址，还需要留意其中的RX/TXerrors、dropped、
overruns信息，大部分情况下它们没什么问题，但是当网卡流量跑满的
时候可能会出现意外。

子主题

sysdig可以分析系统级和进程级许多方面的状况，例如，系统调
用、网络统计、文件I/O等，现在我们用它捕获某个进程到某个IP的网
络流量。
通过proc.pid指定要捕获的进程，fd.cip过滤特定IP地址，evt.buffer
contains指定要过滤的文本内容，此处我们以捕获ES的ping请求为例

子主题

t3.xx.xx.net$T
sysdig还可以将捕获的数据录制为文本或二进制格式，关于该工具
的更多详细信息可以参考官网：http://www.sysdig.org/。