搜索页偶尔 500，OpenSearch 返回 circuit_breaking_exception。重启集群后暂时恢复，高峰期又出现。熔断器是在保护节点避免真正 OOM，第一步不是把限制无限调大，而是找出哪类请求占用了异常内存。
把失败请求和集群内存放在同一时间线上
记录 Magento request ID、搜索词、筛选项、Store View、结果页码和发生时间。OpenSearch 侧查看 heap、GC、breaker、线程池拒绝和慢日志。只有某个复杂筛选失败，可能是聚合问题；所有查询都失败，可能是集群已长期高压。
curl -sS 'http://search-host:9200/_cluster/health?pretty'
curl -sS 'http://search-host:9200/_nodes/stats/jvm,breaker,indices?pretty'
curl -sS 'http://search-host:9200/_cat/indices?v'接口可能暴露内部信息，只应在受控网络使用，不要把完整输出公开。
高基数字段和大聚合是常见元凶
分层导航会对可筛选属性做 aggregation。把几乎每个商品都不同的文本属性设为可筛选，bucket 数量会巨大。检查新近启用的 layered navigation 属性、字段类型和 doc_values。业务不需要的筛选应关闭，而不是让集群为它预留更多内存。
深分页、超大的 pageSize、通配符前缀和同时请求大量聚合也会放大内存。前端应设置合理分页上限，避免为了总数一次取回大量文档。
索引与分片布局也影响单节点压力
太多小分片会消耗大量固定开销，太少且过大的分片又让查询集中。检查索引前缀是否残留多套旧环境索引、replica 是否适合节点数、分片是否均匀。不要在故障时直接删除看不懂的索引，先确认 Magento 当前别名和回滚需求。
调 heap 只能在证据支持时进行
容器限制、JVM heap 和宿主机内存必须匹配，不能让 JVM 认为有更多内存而被系统 OOMKill。调整后观察 GC 暂停、查询延迟与缓存命中，而不是只看熔断消失。
最终用真实搜索词、最复杂筛选、空关键词和高并发分别压测。熔断为零、heap 能回落、P95 延迟稳定，并且业务筛选结果没有被错误删减，才是完成。
