背景

1.ES PAAS管理的集群升级了100+，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群）

2.由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障：“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了，IO也有明显抖动

排查与分析

1.发现YoungGC频率变高了一些，猜测可能是G1GC的问题（我们使用JDK11重新打了ES镜像），经过版本替换，没有明显变化。

参考issue：https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的case，经过测试，不属于我们的场景。

2.多次执行hot_threads API观察， 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据，发现是 FST、DocID 读取慢

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少，使用的是niofs。可知，7.5版本的FST是在堆外，但是_id字段是在堆内。升级到7.17版本后，FST在堆外，该字段也放到了堆外（官方版本应该是7.9就开始放到堆外了）。数据放到堆外，其实也就是文件放到磁盘，读一次之后放到pagecache。

这样也就可以解释了，在upsert类请求多的时候会频繁查询docId，此时如果_id字段没有进入pageCache或者被踢出pageCache，那么就会出现响应慢，并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内（开源版需要改造）

可以看到，CPU有显著下降，也相对均衡。（之前蓝色线高，是因为该节点有大量的主分片）

结论

1.update、upsert、get等请求如果十分频繁，_id使用offheap将不会是个好的选择，除非给足够的堆外内存，并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下，实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障，可能不会有这么明显的差距。（官方描述写入速度仅降低了1.8%）

4.最后吐槽一下，写入不停的情况下，translog的恢复实在是太慢了，由于大分片恢复/rebalance时，translog不会被清理，导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

• 一次使用多台计算机（形成一个集群），以便它可以并行处理数据，从而更快地完成工作。我们可以这样想。如果一台服务器需要处理 100 TB 的数据，它可能会在 500 小时内完成。但是如果我们有 100 台服务器，每台只能取一部分数据，例如 server1 可以取第一个 TB，server2 可以取第二个 TB，以此类推。现在他们每个人都只有 1 TB 的数据要处理，而且他们都可以同时处理自己的数据部分。这样，工作可以在 5 小时内完成，而不是 500 小时。当然，这是理论上的和想象的，因为在实践中我们不会减少 100 倍所需的时间，但我们可以非常接近如果条件理想。
• 在需要时可以很容易地调整计算能力。有更多的数据要处理，而问题要复杂得多？将更多计算机添加到集群。从某种意义上说，这就像在超级计算机上增加了更多的 CPU 内核。
• 数据不断增长，因此 Hadoop 也必须能够轻松灵活地扩展其存储容量，以满足需求。我们添加到集群的每台计算机都会扩展 Hadoop 分布式文件系统 (HDFS) 的可用总存储空间。
• 与其他软件不同，它不仅会在硬件故障发生时尝试从硬件故障中恢复。设计理念实际上假设某些硬件肯定会失败。当有数千台计算机并行工作时，可以保证某处某处会不时出现故障。因此，默认情况下，Hadoop 创建数据块的副本并将它们分布在单独的硬件上，因此当偶尔的服务器起火或硬盘或 SSD 死机时，不会丢失任何内容。

• 当我们需要从数十亿个网站中提取数据时，就像谷歌这样的搜索引擎所做的那样，我们会发现像 Elasticsearch 及 Hadoop 这样的工具非常有用和高效。
• 当我们需要以这样一种方式存储数据并对其进行索引以便以后可以快速有效地搜索时，我们会发现像 Elasticsearch 这样的东西非常有用。
• 最后，当我们想要收集实时数据时，例如来自互联网上许多交易所的美元/欧元价格，我们会发现像 Logstash 这样的工具非常适合这项工作。

1. 目前大会报名购票通道已重新开启，欢迎有兴趣的朋友报名参会，已经报名参会者无需再次报名。报名链接：https://www.bagevent.com/event/7899116
2. 如需要加入本次大会微信交流群，请加微信(lsy965145175)拉群。
3. 更多大会资讯请关注官网：https://conf.elasticsearch.cn

2022国际开源节（IOSF）由OSTech联合中国信息通信研究院、Linux基金会亚太区发起策划，在ELEXCON深圳国际电子展暨嵌入式系统展落地，并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、O3DF、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构，GDG、开源中国等全球知名开发者社区，以及上海开源信息技术协会等权威开源机构的共建支持。
国际开源节旨在汇聚全球开源技术与项目，融合国际文化、开源社区生态和开源产业发展，构建“共创共赢”的开源文化，打造中国开源新生态。
2022国际开源节（IOSF）将同期举办前沿技术峰会，主题涵盖“国际开源教育与人才培养论坛”、“OpenSSF开源安全中国峰会”、“Kubernetes on AI & Edge ”、“Hyperledger超级账本峰会” 、“CNCF云原生论坛”、“开源投融资论坛 ”、“高校学术开源峰会”、“O3DF元宇宙论坛”，敬请期待！

合作联系

参展合作（微信同步）
Tony,13713437040；
Friday，17612060999；
宣传合作（微信同步）
Cindy,13553827402；
Katharine,13512772116；

背景

1.对于7版本（大版本）集群希望只维护一个版本，最终选择7.17，对同大版本的7.5版本集群进行升级

2.根据官方描述，_id放到堆外性能损失非常小可以忽略，且对BKD进行了优化

3.升级完成，一段时间之后，收到用户报障

4.抽样检查了下部分升级的集群，其中部分受到影响，部分不受影响。且每个集群内存均有一定优化（预期内）

调查&分析

1.发现is_deleted文档特别多，怀疑是7.17版本对于碎片过于敏感。做forcemerge，没什么效果。

2.GET _nodes/hot_threads 查看耗时部分，结果展示笼统，没得到关键信息。

3.给语句加上profile，查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来，主要是 status、pId 字段耗时高，这两个字段都是integer类型，并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题，进一步排查：使用arthas工具获取一段时间内的火焰图

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题：https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差，看起来官方描述的BKD相关优化指的是range

7.测试验证，将字段改成keyword，查看结果，CPU查询耗时恢复到正常范围