/tags/lucene/ Recent content in lucene on Hugo -- gohugo.io en Tue, 29 Sep 2026 09:00:00 +0800 /posts/opensearch-index-content-audit/ Tue, 29 Sep 2026 09:00:00 +0800 /posts/opensearch-index-content-audit/ 一台 OpenSearch 3.5.0 单节点存着 qa、stg、preprod 三个非生产环境的日志，保留 14 天，共 47.5 GB、1,456 个索引（文中的 GB、MB 按 OpenSearch 的口径，指 GiB、MiB）。512 GB 的磁盘只用了 18%，容量并不紧张，这次审计要回答的是这 47.5 GB 花在了哪里、哪些可以在源头去掉。 最大的 8 个索引族共约 41 GB，占全部数据的 86%，估算其中约 34 GB 可以在源头优化掉。最大的 api-request-logs-stg（26 GB）里，一个接口的完整响应体就占了约 23 GB。 Lucene 文件后缀的占比 一个分片由多个段（segment）组成，每个段是一组后缀不同的文件，分别存放原文、倒排索引和 doc values（见 Lucene 的文件格式说明）。各取两个索引族 9 月 25 日的单日索引，按 Lucene 文件类型统计磁盘占比：api-request-logs-stg 这一天是 1,770 MB，stg-bet-processing-general 是 559 MB；compound 文件（小段打包存放的格式）没有计入，它们的构成和其余段相近。 文件后缀 存放的内容 api-request-logs-stg（API 请求日志） stg-bet-processing-general（业务应用日志） .fdt stored fields，也就是 _source 原文的压缩块 42.9% 73.4% .pos 词项在文档中的位置，短语查询和邻近查询要用 32.5% 11. /posts/opensearch-dev-ism-task-lock-overhead/ Mon, 28 Sep 2026 09:00:00 +0800 /posts/opensearch-dev-ism-task-lock-overhead/ 一台 OpenSearch 3.5.0 的开发环境单节点，装着 qa、stg、preprod 三个环境的应用日志，数据总量只有 47.5 GB，14 天滚动删除。按这个数据量，4 vCPU 的机器应该很闲，CPU 和磁盘写入却一直不低。 现象 节点启动 7.9 天以来，OpenSearch 平均占用 0.88 核 CPU；一次 60 秒的采样窗口里是 1.2 核，占 4 核的 30%。实际负载很小：每秒写入 124 条文档，1,456 个索引里只有 33 个在写，没有一个被查询。磁盘只用了 18%，整盘写入却有 1.69 MB/s、120 IOPS。 排查：磁盘写入的大头在哪 把 60 秒内 OpenSearch 各线程的磁盘写入量拆开，按线程名对应到内部的操作类型。占比按各线程合计的 1,225 KB/s 计算，表里只列了写入最多的四类： 线程 写入速率 占比 对应的操作 system_write 844 KB/s 69% ISM 任务锁索引和配置索引的写入、refresh 产生的新段 write 248 KB/s 20% 业务日志的 translog 和段写入 refresh 65 KB/s 5% 定时 refresh management 50 KB/s 4% 管理类后台任务 将近七成的写入落在 system_write 线程上，业务日志的写入只占两成。同一窗口里 merge 输出 110 KB/s，其中 96% 也来自这两个系统索引。