Elasticsearch实战-磁盘IO被打满 - 编程一生
内容提要
测试环境ES因索引分片过多、副本多且磁盘性能差，导致单机IO打满、查询超时。优化建议：改用SSD，分片减至2个，副本减为1，并引入Tair缓存，让ES仅处理复杂查询以减轻压力。
延伸解读
分片与副本的配置权衡
文章指出，该索引仅100MB却设置了10个分片和4个副本，导致读写QPS均超过1000时磁盘IO被打满。分片过多会使查询分散到多台机器，引发木桶效应；而副本过多会同步写放大，加剧磁盘压力。由于机器数少，10个分片实际每台分布5个，等效于2个分片，并未提升写能力。因此，分片和副本并非越多越好，需结合数据量、机器数量和读写比例综合设定。
硬件与架构的优化方向
针对IO瓶颈，ES团队建议升级为SSD，并将分片减至2个、副本减为1个。文章解释，分片减少可提升读能力且写能力等价，副本减少则直接降低同步写开销。此外，因数据量很小，可考虑用Redis替代ES存储，或在ES上层增加Tair缓存，让ES仅处理复杂查询。这些措施旨在从存储介质、索引结构和访问路径三方面减轻磁盘压力。
集群均衡与客户端局限
调查发现，10台VM中仅一台IO打满，其他负载很低，说明ES自身的负载均衡和服务发现机制可能存在问题。ES团队回复称其服务发现是自研的，客户端仅对官方客户端做了简单封装，目前人力不足无法改造，预计10月左右推出自研客户端以缓解单机查询问题，但无法根本改变ES内部机制。这提示读者，在依赖ES时需关注集群均衡性，并留意客户端版本可能带来的风险。
平滑替换与运维实践
对于硬件升级，文章明确无需换成物理机，因为ES内存最多用32G，物理机多出的内存会被浪费，通常也会隔成VM使用。原有10台VM数量足够，可同等数量替换。替换时先申请机器部署，再通过机器替换功能逐台将分片迁移到新机器，一台迁移完成后自动下线老机器，实现平滑过渡。但分片数调整需要重建索引，难以平滑进行，因此只减少了副本数。
Q&A
测试环境ES磁盘IO被打满的原因是什么？
主要原因是索引分片过多（10个分片、4个副本），导致查询时需访问多个分片，容易产生木桶效应；写入时由于机器数少，每台机器分布多个分片，实际写能力未提升；同时测试环境磁盘性能差，加剧了IO压力。
如何优化ES集群配置以减轻磁盘IO压力？
建议将分片数减少到2个，副本数减少到1个；升级硬件为SSD；在ES上层增加Tair缓存，让ES仅处理复杂查询请求。
为什么ES分片数多反而可能导致写入性能下降？
因为写入时虽然分片多，但机器数少，导致每台机器分布多个分片，等效于只做了少量分片，无法扩大写能力，反而可能因资源竞争降低性能。
是否应该将测试环境ES的虚拟机替换为物理机？
没有必要。因为ES内存最多能用32G，物理机多出的内存用不上，通常也会隔成虚拟机使用。原有10台虚拟机数量足够，只需同等数量替换，并利用机器替换功能平滑迁移分片。
在程序层面如何优化以减少对ES的压力？
可以在ES上层增加Tair缓存。对于数据更新操作采用单个数据读取，利用Tair更好的事务性，减少对ES的访问，让ES只处理复杂查询请求。
ES团队对于负载均衡问题有什么后续计划？
ES团队预计在10月份左右推出自研客户端，尽量避免一台机器导致部分查询出现问题，但无法改变ES内部的服务发现机制，除非修改ES本身。
