Elasticsearch执行cat allocation时disk.indices大于disk.used原因咨询

现象原因解释 #

该差异是两个指标的统计口径、存储层优化共同导致的，常见触发原因有三个：

• 索引压缩优化：Elasticsearch底层基于Lucene实现，默认对索引数据执行多层压缩：包括文档内容的LZ4/ZSTD通用压缩、数值字段的增量编码/游程编码、倒排索引的字典压缩等，实际落盘的物理大小普遍只有索引逻辑统计大小的1/2到1/5。disk.indices统计的是索引的逻辑大小，disk.used是操作系统层面统计的实际物理磁盘占用，因此会出现前者远大于后者的情况。前四行节点磁盘占用率高，是因为节点上的热数据段合并已经完成，且没有高压缩率的冷数据，逻辑和物理大小差异较小。
• 存储层特性：如果集群使用了支持精简制备（Thin Provisioning）、重复数据删除的企业级存储（分布式块存储、SAN/NAS等），存储层会自动合并重复数据块，尤其是同索引的主副本分片存在大量重复数据块的场景下，实际物理占用的空间会远小于Elasticsearch上报的索引逻辑总大小。
• 元数据异步更新：disk.indices是Elasticsearch内部维护的元数据统计值，更新逻辑是异步的，而disk.used是实时调用操作系统接口获取的统计值。如果节点最近刚完成大量段合并、索引删除操作，Elasticsearch的元数据还没完成同步，也会出现临时的指标差异，一般数分钟后就会自动对齐。

你可以登录对应节点进入Elasticsearch的数据目录，执行du -sh命令查看实际物理占用，如果数值和disk.used匹配，说明该现象是正常的存储优化导致，不会影响集群正常运行。

内容的提问来源于stack exchange，提问作者Sandeep Kanabar