京公网安备11010502063487号真实查_nodes/stats/breaker发现6种断路器同时存在，parent断路器单独统计出518.8mb占用而非其他子断路器的简单加总；把request断路器限制压到1kb后跑3万桶聚合真实精确触发circuit_breaking_exception，报错写出想要分配6144字节但限制只有1024字节；tripped计数器确认记录了这次触发，恢复默认限制后聚合立刻重新成功。
真实用Xms=Xmx=1g启动时committed跟max精确相等；改成Xms=512m/Xmx=1g重启后committed只有512MB跟1GB的max对不上，量化了Xms不等于Xmx的真实风险；随后灌数据跑重聚合想撑大堆，committed却稳稳停在512MB没涨，诚实记录这个负面结果说明风险暴露与否取决于实际工作负载。
真实用ps查ES进程RSS是1421MB比1024MB堆上限还大，证明存在off-heap内存；用vmmap查虚拟内存发现VSZ高达469GB，Guard区域虚拟385GB但resident为0；细看mapped file区域发现178.4MB映射只有16.5MB真实resident，列出的具体文件正是本机es-lab数据目录下真实的Lucene段文件。
真实查主力es-lab节点max_file_descriptors是10240；临时搭建节点用ulimit -n 1000压低上限启动后，节点自报值精确变成1000；查启动日志发现WARN级别bootstrap check警告提醒上限太低，但没有阻止节点启动，最终照常达到green，揭示单节点绑定本地场景下是警告而非硬性阻断。
本机没有root权限purge被拒绝；造160MB索引立刻查询建立1毫秒warm基线；读取4.1GB无关数据制造压力后重查平均耗时依然1毫秒没有变化，诚实记录这个负面结果，说明16GB内存相对测试数据量太富余，操作系统优先回收inactive页面不会动到刚被访问过的热数据。
本机没有能注入磁盘延迟的工具，改为建两个数据一致的索引对比mmapfs和niofs存储策略，查询和写入侧各3轮交替对比都测不出可感知差异，诚实记录这个负面结果，揭示磁盘延迟真正造成影响的前提是磁盘本身要慢，本机足够快的本地SSD不足以暴露两种策略的理论差异。
真实搭建独立节点开启security和audit日志，故意制造两次失败认证请求，发现审计日志里没有留下任何失败记录；显式配置完整事件类型清单重测后依然如此；翻server日志找到真实根因——WARN日志明确写出Auditing logging is DISABLED因为当前license是BASIC，揭示审计日志功能受License等级约束，配置开关打开不代表真实生效。
真实查_health_report发现8个独立indicator都带人话描述的symptom；建默认1副本索引制造yellow后shards_availability真实给出完整diagnosis(cause/action/help_url/受影响索引)；对比老的_cluster/health只给unassigned_shards:1这个数字没有任何解释，展示新旧健康检查接口的诊断能力差距。
真实搭建3节点集群，1个节点配成不参与master选举的纯data角色，确认一个主分片落在该节点上后kill掉它，master真实完全没有变化没有触发选举，原主分片立刻被提升到还活着的副本上，集群只降级到yellow且数据完全可读，揭示角色分离设计限制故障影响面的真实价值。
真实用hdiutil创建300MB磁盘镜像作为节点数据目录，连续灌数据直到真实物理耗尽，触发file_system_exception报错No space left on device；更严重的是磁盘耗尽后单节点连确认自己是master都做不到，DELETE删索引自救请求也卡死不响应，揭示真实磁盘耗尽远比水位阈值触发的只读保护严重。
真实用python往Lucene segment文件中写入乱码制造数据损坏，重启后集群变red，allocation/explain精确捕获checksum校验失败的CorruptIndexException；retry_failed和allocate_empty_primary都没能干净解决，最后直接DELETE整个索引反而最有效立刻拉回green，印证snapshot才是对付真正数据损坏的真实解药。
真实搭建3节点全员master候选集群，kill掉当前master后用紧凑轮询精确测出新master只花0.22秒就选出来；切换过程中数据可用性几乎零中断，之前文档可查新写入立刻成功且primary_term跳变确认主分片提升；重启的老master只以普通节点加入不要回master身份。