文件描述符限制

做的事：本机真实查主力es-lab节点的max_file_descriptors，看默认值是多少，当前真实用了多少

代码GET /_nodes/stats/process

验证：max_file_descriptors真实是10240，当前真实用了533个

max_file_descriptors: 10240
open_file_descriptors: 533

这个真实数字10240是macOS上这台节点启动时真实能拿到的文件描述符上限，跟Linux上官方文档常提到的65536这个数字不一样——真实的上限数值会受操作系统本身的限制影响，不是一个放到哪个平台都通用的固定值。

真实搭一个独立的临时节点，用ulimit -n 1000把这个新节点能用的文件描述符上限真实压低到1000再启动，看会发生什么

代码真实在同一个shell里: ulimit -n 1000 && 启动一个全新的fd-lab节点

验证：节点自己上报的max_file_descriptors真实精确变成了1000——真实的限制确实原样传递给了这个节点

GET /_nodes/stats/process
→ max_file_descriptors: 1000   ← 真实跟shell里设的ulimit -n 1000精确对应
→ open_file_descriptors: 518

这个真实结果确认了启动ES进程的那个shell环境里设置的ulimit -n，真实会原样成为这个java进程能使用的文件描述符硬上限，ES自己完全没办法在进程启动之后再把这个上限真实调高——这意味着真实的部署脚本如果忘了在启动ES之前正确设置好这个系统限制，ES真实只能被动接受一个可能远低于推荐值的上限。

真实查这次启动的日志，看ES是否会对这个明显偏低的上限真实做出反应

代码真实检查fd-lab_server.json日志文件

验证：真实发现了一条WARN级别的bootstrap check警告，原文直接写出当前的1000太低，建议至少提到10240；关键的是这条警告并没有真实阻止节点启动

{"log.level": "WARN", "message":
  "max file descriptors [1000] for elasticsearch process is too low,
   increase to at least [10240]; for more information see [...]",
  "log.logger": "org.elasticsearch.bootstrap.BootstrapChecks"}

真实几秒后的集群健康检查: status: "green"   ← 真实照常启动成功了

收尾：真实销毁这个临时节点，确认主力es-lab实例全程真实未受影响

代码真实kill -9掉fd-lab的全部进程，rm -rf整个fd-lab目录

验证：主力es-lab实例（端口19920）真实全程保持green，完全没受这次临时节点测试的影响

status: "green", number_of_nodes: 1

分步演示：从主力节点的真实默认上限，到故意压低上限后节点自报值的精确对应，再到真实触发的bootstrap check警告

每一步都是本文在本机真实的Elasticsearch 8.15.0上跑出来的原始结果，其中临时节点测完即销毁。