INFINI Agent v1.31.0 带来了本版本最重要的特性——Easysearch 安装向导。用户无需手动编辑任何配置文件，通过图形界面即可完成 Easysearch 集群的安装、配置和日常管理。

Easysearch 安装向导

一键拉起新集群

向导支持开发模式和生产模式两种方式创建 Easysearch 节点。用户只需填写集群名称、节点名称、监听地址、端口、数据目录等基本信息，向导便会自动完成软件下载、JDK 配置、安全证书生成、参数配置、插件安装、节点启动等全部步骤，并实时展示每一步的进度，支持随时暂停和恢复。

一键加入已有集群

通过粘贴现有集群提供的 Token，向导可自动从目标集群拉取证书、版本、插件等配置信息，完成新节点的安装和接入，全程无需手动复制任何证书文件。

安装前环境预检

向导在开始安装前会对当前机器进行全面检测，帮助用户提前发现潜在问题：

• 操作系统和 CPU 架构是否受支持
• 内存是否满足推荐要求
• 端口是否已被占用
• 数据目录磁盘空间是否充足、路径是否可写
• 系统参数（文件描述符限制、内核 max_map_count 等）是否满足 Easysearch 运行需求
• TLS 证书填写后实时校验有效性，包括证书链完整性和过期时间

TLS 安全证书灵活配置

支持三种证书配置方式，满足不同安全需求：

• 自动生成：向导一键生成自签名证书，无需任何证书知识
• 手动上传（共享）：为 HTTP 和节点通信层提供同一套证书
• 手动上传（分离）：为 HTTP 层和节点通信层分别提供独立证书

完整的服务生命周期管理

集群建好后，向导提供持续的管理能力：

• 启动、停止、重启 Easysearch 节点

• 在线安装和卸载插件

• 在线编辑配置，包括 easysearch.yml、JVM 参数、日志配置、证书配置

• 在线日志排查：内置日志阅读器，支持查看节点日志文件列表，并提供类似 tail -f 的自动滚动功能，无需登录服务器即可快速定位报错。”

网络受限环境支持

针对无法直接访问外网的环境，向导支持配置 HTTP 代理，所有软件包（Easysearch、JDK、插件）均可通过代理下载，并提供连通性测试功能。

获取新版本

INFINI Agent v1.31.0 已正式发布，欢迎升级体验：

• 下载地址
• 用户手册

15,000 条 heavy-OR 规则，200,000 条文档，同一台机器：Easysearch 在线规则引擎全流程 11.68 秒，Percolate Query 仅搜索阶段就跑了 254.30 秒——慢了 21.8 倍。

在"规则先存、文档后到"这类场景下，Percolate Query 的延迟会随规则数量和复杂度的增长快速恶化。规则涨到数千条后，每批文档匹配的耗时可以从秒级攀升至几分钟。这类问题换索引参数、调批次大小、精简 DSL，都治标不治本，根子在执行模型本身。

本文通过一组 heavy-OR 基准测试，量化两种方案的实际差距。

测试配置

测试在同一台主机上运行，使用同一套规则文本和文档样本。Percolate Query 的查询条件由相同规则翻译而来，保证两侧规则语义一致。

测试结果

具体指标：

• Easysearch 在线规则引擎全流程：11.68s
• Percolate Query 搜索阶段：254.30s
• 差值：242.62s
• 倍数：21.76 倍
• 每批（10,000 文档）平均耗时：Easysearch 约 0.49s，Percolate Query 约 12.69s

开启规则引擎的增量成本

规则匹配会对写入链路产生多少额外开销，是评估在线规则引擎可行性的重要指标之一。

与之对比，Percolate Query 仅搜索阶段就需要 254.30s。换言之，Easysearch 在线规则引擎把规则匹配叠加进写入流程，新增成本约为 Percolate Query 搜索耗时的 1/44.9。

只看匹配引擎本体

上一组数据（11.68s vs 254.30s）包含了 Easysearch 的在线写入、bulk 解析和索引处理等通用开销。为了单独衡量规则匹配引擎自身的性能，我们用 Java 直调 JNI 做了一次离线 match，绕过写入链路，只跑规则匹配逻辑。

这组数据说明两点：Easysearch 的性能优势并非来自写入链路的整合效率，即便剔除通用写入成本，规则匹配引擎本体与 Percolate Query 之间依然存在约 50 倍的差距。

为什么 Percolate Query 会慢

根因在执行模型，OR 条件多只是放大器。

每批文档到达时，Percolate Query 都要走完这套流程：

1. 把文档放进临时内存索引
2. 基于规则中的 terms 筛选候选规则
3. 对候选规则逐条验证

以本次测试为例，各阶段耗时分布如下：

• 规则翻译：9.560294s
• 规则导入：7.451857s
• percolate 搜索：254.304583s

搜索阶段是每批文档都必须重新支付的代价。

Heavy-OR 规则在这套流程里两头放大：规则覆盖面广，候选集更难剪掉；单条规则条件多，逐条验证也更重。

Easysearch 规则引擎把规则提前编译好，文档到达后直接匹配，不走这套每批重建的流程，差距就在这里。

适用场景

以下场景对规则匹配的吞吐和延迟要求较高，是 Easysearch 在线规则引擎的典型适用范围：

• 内容审核：规则持续增长且复杂度高，需要稳定的处理吞吐，对单批延迟敏感。
• 舆情监测：热点词、别名、邻近词组合多，规则天然形成大 OR 结构，是 Percolate Query 最容易触及性能瓶颈的场景。
• 广告定向：人群包条件不断叠加，文档流量高，规则匹配需要足够轻量，避免影响整条投放链路。
• 告警规则：延迟直接影响告警有效性，规则命中需要尽量贴近文档写入时刻。
• 实时反欺诈：规则复杂、变更频繁、吞吐高，要求文档到达后立即完成判断。

小结

在本次 heavy-OR 基准测试中：

• 相同规则集（15,000 条）和文档量（200,000 条），Easysearch 在线规则引擎全流程耗时 11.68s，Percolate Query 仅搜索阶段耗时 254.30s，相差 21.8 倍。
• 开启规则引擎带来的写入链路增量成本为 5.66s，约为 Percolate Query 搜索阶段耗时的 1/44.9。
• 剔除写入通用开销后，规则匹配引擎本体的差距约为 50 倍。

如果你的业务已经有 Percolate Query 延迟随规则增长持续上升的问题，不用看 demo 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。

规则引擎功能当前需要试用 License。你可以先下载 Easysearch：https://infinilabs.cn/download，再联系售前申请试用 License 并获取开通指引。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• Easysearch ZSTD 基准测试：高压缩率下实现近 5 倍查询吞吐
• Easysearch 2.0.0 性能测试
• Easysearch 时序数据的基于时间范围的合并策略
• Easysearch Rollup 相比 OpenSearch Rollup 的优势分析
• Easysearch Rollup 使用指南

最近一次高并发写入压测中，我们遇到了一个非常诡异的 BKD merge 崩溃。从报错看，很像 Easysearch 2.1.2 在 merge 阶段把 segment 读成了错误状态。典型错误是这样的：

java.lang.ArrayIndexOutOfBoundsException: Index -3 out of bounds for length 8
java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8

异常栈最终落在 Lucene BKD 相关路径上：

• BKDReader.readNodeData()
• BKDWriter.merge()
• Lucene90PointsWriter.merge()

如果只看栈，很容易把问题归到 Easysearch 的 BKD merge 逻辑。但排查到最后，结论恰恰相反。

问题不在 Easysearch 的代码，而在 JDK 运行时。 更精确地说，是某个特定 Oracle GraalVM 21 构建中的 JVMCI/Graal JIT 路径，把 Lucene BKD 的热点代码执行错了。

1、为什么这个问题难查

它有几个特别迷惑人的特征：

• 只在高并发写入压测下触发
• 服务重启后的前几轮最容易复现
• 同一进程里，删了索引重新压，后面复现率反而下降
• 不是固定字段，多个数字类型字段都中过招
• ZSTD 和 best_compression 两种 codec 下都能复现

实际命中过的字段包括 @timestamp、size、status、_seq_no。所以这不是某个字段、某种 codec 或某个 mapping 的偶发问题。

2、第一层排除：merge reader 不是第一现场

一开始我们确实怀疑 merge reader，毕竟异常直接出现在 merge 路径上。但日志顺序很快给出了相反的证据。在 merge 真正崩溃之前，source segment 已经先出现了这些异常信号：

1. point-sort-restore-multiple-zero-ords
2. source-write-point-doc-mismatch
3. pointCount > docCount
4. pack-index-negative-code
5. reader-invalid-start-pos
6. 最后才是 ArrayIndexOutOfBoundsException

这意味着两件事：merge reader 不是第一现场，source segment 在写出阶段就已经坏了。merge reader 只是读到了已经损坏的 BKD index，并在那个阶段暴露了异常。

3、第二层排除：Easysearch 自己的 BKD 写入逻辑也没有先出错

继续往前追溯，我们发现问题比 OneDimensionBKDWriter.add() 还要早。真正的异常出现在排序/回填链路上：

• PointValuesWriter
• MutablePointTreeReaderUtils.sort()
• StableMSBRadixSorter

关键证据来自两个探针：

• point-sort-restore-multiple-zero-ords
• unwrittenSlotCount == source-write-point-doc-mismatch delta

这说明在某次排序/回填过程中，有一部分槽位根本没有被写入，默认值 0 被 restore 回填到 ords[]，再通过 docIDs[0] 放大成大量 docID=0，最终导致 pointCount > docCount，source segment 进入错误状态。

到这一步，排查重点已经不是“Easysearch 的 BKD merge 逻辑存在缺陷”，而是 Lucene points 排序链路的执行结果和源码语义不一致。

4、真正的转折点：抓到了 reorder() 自身的 coverage 异常

真正把方向扭转过来的，不是又一次复现，而是一个更早的探针：

• point-sort-reorder-coverage-mismatch

这个探针验证的是：StableMSBRadixSorter.reorder() 是否真的按源码应有的次数完整执行。

我们抓到的典型样本之一如下：

• targetSegment=_x
• field=status
• k=7
• expectedLoopCount=9800
• actualIterationCount=8204
• firstCoverageMismatchBucket=201
• firstCoverageExpected=9788
• firstCoverageActual=8192

更关键的是，同一条日志里还带出了这个信息：

skippedSourceSamples=[201:[{ord=8192,bucket=201,docID=9090,byteAtK=200}, ...]]

这条信息非常重要，因为它说明：bucket 201 理论上应该处理 9788 条，实际只处理了前 8192 条，但从 ord=8192 往后的样本，读出来仍然还是 bucket=201。这直接推翻了“后半段数据被污染后改桶”的旧解释，指向了一个更直接的结论：reorder() 自己的 coverage 被截断了。

另一个样本中出现了同类边界：firstCoverageExpected=31822，firstCoverageActual=16384。

到这里，一个很不自然的特征浮现出来：8192、16384——这些明显的 2 的幂边界，更像是运行时或 JIT 执行异常，而不是普通业务逻辑 bug。

5、哪段代码最可疑

此时怀疑对象已经不是泛泛的“BKD 整体有问题”，而是 Lucene 中的这段热点循环：

for (int i = 0; i < HISTOGRAM_SIZE; ++i) {
  final int limit = endOffsets[i];
  for (int h1 = fixedStartOffsets[i]; h1 < limit; h1++) {
    final int b = getBucket(from + h1, k);
    final int h2 = startOffsets[b]++;
    save(from + h1, from + h2);
  }
}
restore(from, to);

代码位于 org.apache.lucene.util.StableMSBRadixSorter#reorder(...)。

按源码语义，这段代码应该完整扫描每个 bucket 的范围，并最终把全部结果 restore 回去。但我们抓到的事实是：expectedLoopCount != actualIterationCount，某些 bucket 只跑到 8192 / 16384 就停了，随后出现未写槽位，restore 把默认 0 回填，最终 source segment 进入错误状态。

如果这是 Java 源码本身的稳定逻辑 bug，它在解释执行时也应该稳定触发，而不应该强烈依赖某个 JDK/JIT 组合。后面的 JVM 对照实验基本排除了这个可能性。

6、最强证据：只换 JDK / JIT 路径，结果就变了

这次排查中最有说服力的，不是某一条日志，而是对照实验。

基线组：旧版 Oracle GraalVM 21，默认 JVMCI/Graal JIT

环境：

• Oracle GraalVM 21+35.1
• 21+35-jvmci-23.1-b15
• Linux aarch64 / ARM64
• UseJVMCICompiler = true

结果：很快复现，命中了 point-sort-reorder-coverage-mismatch、point-sort-reorder-underfilled、point-sort-restore-multiple-zero-ords，随后 merge 报 ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8。

对照组：关闭 JVMCI/Graal JIT 或纯解释执行

只改 JVM 参数，不改代码和压测口径：

• -XX:-UseJVMCICompiler
• -Xint

结果一致：都没有再出现上述探针和异常。

这三组对照的意义很直接：如果这是 Easysearch 或 Lucene 的纯 Java 逻辑 bug，解释执行也应该能稳定复现。但现实是基线组复现，关闭 JVMCI 和纯解释执行都不复现。问题显然高度依赖 JIT 路径。

版本对照：较新的 GraalVM 21 构建在当前测试中未复现

这里需要补充一条重要的边界条件。我们后来又测试了一个较新的 GraalVM 版本：

java version "21.0.9" 2025-10-21 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 21.0.9+7.1 (build 21.0.9+7-LTS-jvmci-23.1-b79)

在当前压测中，这个版本没有再出现 merge 错误。

因此结论必须写得更精确：已知会复现的是较早的 21+35-jvmci-23.1-b15，已知在当前测试中未复现的是较新的 21.0.9+7-LTS-jvmci-23.1-b79。更准确的工程判断不是“GraalVM 21 整体都有问题”，而是某个特定 GraalVM 21 构建有问题，较新的构建很可能已经修复或规避了该问题。这里仍需保持严谨：只能说“在当前压测中未复现”，还不能直接说“已经被完整证明没有问题”。

平台边界：不能写成 ARM 专属

除了前面详细展开的 Linux aarch64 / ARM64 主要实验环境外，有用户反馈在以下环境中也出现过同类问题：

• 操作系统：openEuler
• 内核：4.19.90-2112.8.0.0131.oe1.x86_64
• 架构：x86_64

这是用户的测试环境，不是我们能够独立完整复现并逐项展开的。但这条信息已经足够说明：当前不能把问题简单写成“ARM 平台专属”。更准确的说法是：我们在 ARM64 上系统性复现并完成了主要对照实验，另外也有 openEuler x86_64 测试环境的同类现象反馈，因此平台边界目前还没有被完全钉死。

7、更强的同机对照：换成 Oracle HotSpot 21.0.10 后，全量写入跑完也没有问题

为了进一步排除“是不是所有 Java 21 都会这样”，我们在同一台服务器上把 /infini/easysearch/jdk 从 Oracle GraalVM 21 换成普通 Oracle HotSpot 21.0.10，恢复默认 JVM 参数，用同样的写入压测继续验证。

其中一轮的结果很有说服力：

• 索引：nginx_zstd3_40mt4
• codec：ZSTD
• threads=16
• bulk_size=1000
• target_docs=181463624

最终 after_count=181463624，delta_written=181463624，全量文档写入完成，服务端没有出现任何 BKD merge 错误。

这条结果至少说明：同一台机器、同一套 Easysearch、同样的数据规模和写入模型，只要把 JDK 从 Oracle GraalVM 21 换成 Oracle HotSpot 21.0.10，问题就不再出现。

到这一步，工程判断已经比较清晰了：不是 Easysearch 自身逻辑导致，也不是所有 Oracle JDK 21 都会出错，更像是特定 Oracle GraalVM 21 构建相关的 JVMCI/Graal JIT 路径问题。

8、最关键的外部对照：Elasticsearch 8.19.5 也复现了

如果说前面的结论还能被质疑为“Easysearch 某些实现差异触发的”，那么后面的外部对照基本排除了这个方向。

我们在同一台服务器上部署了 Elasticsearch 8.19.5（Lucene 9.12.2），JDK 也切到相同的 Oracle GraalVM 21，执行同类写入压测。结果 Elasticsearch 也复现了同样的 BKD merge 崩溃。

关键异常完全一致：

java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8

栈也一样落在 BKDReader.readNodeData、BKDWriter$MergeReader.collectNextLeaf、BKDWriter$MergeReader.next。

这条证据的力度很强：不是 Easysearch 独有的问题，不是当前这套 Lucene 代码路径独有的问题，Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也会出现同类异常。到这一步，再把问题归因于 Easysearch 本身的代码逻辑，已经缺乏依据了。

9、这次排查最终说明了什么

把整条证据链串起来，当前阶段的结论已经比较清楚。

已验证的事实：

• 问题不是 merge reader 先制造坏数据，source segment 在更早阶段就已经进入错误状态
• 不是单字段问题，也不是 ZSTD 或 best_compression 专属
• 已抓到 StableMSBRadixSorter.reorder() 自身的 coverage 异常
• 关闭 UseJVMCICompiler 后问题不复现，-Xint 下也不复现
• 同机切到 Oracle HotSpot 21.0.10 后，Easysearch 全量写入跑完未见 BKD merge 异常
• Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也复现
• 较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前压测中未复现
• 某用户的 openEuler x86_64 测试环境中也出现过同类错误，因此不能写成 ARM 专属

工程结论：

从工程证据来看，Easysearch 本身的代码逻辑没有问题。

当前最符合事实的结论是：问题高度相关于特定 Oracle GraalVM 21 构建，更具体地，是该构建相关的 JVMCI/Graal JIT 路径。它把 Lucene BKD 相关热点代码执行到了错误状态。已知较早构建 21+35-jvmci-23.1-b15 可复现，已知较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前测试中未复现。平台边界目前尚未完全钉死，不能再简单写成仅限 ARM64。

换句话说，这不是“Easysearch 的 BKD merge 实现有 bug”，而是特定 JDK/JIT 运行时把本来正确的 Lucene BKD 代码执行错了。

10、建议版本与规避方案

如果你在生产或测试环境中运行 Easysearch 或 Elasticsearch，并且使用的是某些 Oracle GraalVM 21 构建，且启用了默认的 JVMCI/Graal JIT，那么在高并发写入、频繁 merge、BKD 热点路径被充分打热的场景下，需要特别警惕这类问题。

现阶段比较明确的建议是：

1. 避免继续使用已经验证可复现的旧版构建：Oracle GraalVM 21+35.1 或 21+35-jvmci-23.1-b15
2. 优先升级到当前测试中未复现的版本：Oracle GraalVM 21.0.9+7.1（即 21.0.9+7-LTS-jvmci-23.1-b79）
3. 如果短期内不方便升级 GraalVM，直接切换到普通 Oracle HotSpot 21.0.10

直接落到版本号上会更清晰：

• 已确认应避开：21+35-jvmci-23.1-b15
• 当前更推荐：21.0.9+7-LTS-jvmci-23.1-b79

原因很简单：前者我们已经复现了，后者在当前压测中没有复现。当然，这里的“推荐”是基于当前测试结果，不代表上游已经正式确认该问题已被修复。

11、最后

这次排查最大的价值，不是“又复现了一次 BKD merge 崩溃”，而是把一个看起来像 Easysearch 代码 bug 的现象，收敛成了一个有明确边界的运行时问题。

它至少说明两件事：

• 栈顶报错的位置不一定是真正的第一现场
• 真正有说服力的不是猜测，而是对照实验

这次结论之所以成立，不是因为主观判断，而是因为我们已经拿到了足够强的工程证据：同机 HotSpot 不复现，关闭 JVMCI 不复现，解释执行不复现，Elasticsearch 也复现，较新的 GraalVM 21.0.9+7.1 在当前测试中未复现，且某用户的 openEuler x86_64 测试环境也出现过同类错误。

所以，这一次，问题确实不在 Easysearch，而在特定版本的 JDK/JIT 运行时。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• Easysearch 国产替代 Elasticsearch：8 大核心问题解读
• Elasticsearch VS Easysearch 性能测试
• 从 Elastic 迁移到 Easysearch 指引
• Elasticsearch 磁盘空间异常：一次成功的故障排除案例分享
• Easysearch、Elasticsearch、Amazon OpenSearch 快照兼容对比