同一份 Spring MVC + 虚拟线程的 SSE 代码，4 核 8 GB 容器里 Tomcat 每条连接占 112.3 KB 存活堆（移到堆外后 98 KB），5.2 万条撞堆墙；换 Jetty 是 18.3 KB，WebFlux 每连接 RSS 最低。

生产环境单节点 OpenSearch 的 Dashboards 对所有用户返回 401：按 _id 排序分页留下的 12.3 GiB fielddata 占着没有上限的缓存，几个跨月聚合又把堆推过了 parent 断路器上限。文中整理了时间线、原因和防护建议。

按峰值每秒 6 万到 7 万条、每天约 2.4 TB 主分片数据推算日志集群：Kafka 缓冲、节点角色分离、写入调优和 data stream 滚动；热数据在 14 台本地 NVMe 节点上保留 7 天，快照在 S3 保留约 30 天。

三个非生产环境 14 天共 47.5 GB 的日志里，一个接口的完整响应体估算占了约 23 GB。按文件后缀、字段抽样、mapping 开销和查询模式四步找出空间去向，并估算源头截断、zstd、去掉长文本 .keyword 和不存位置信息各能省多少。

开发环境单节点只存 47.5 GB 日志，OpenSearch 却平均占 0.88 核。大头是 ISM 每 5 分钟对 1,388 个索引加锁放锁，锁索引两天多才 flush，软删除攒到 185 万条；在线调参后预计降到 0.2～0.25 核。

选 UUIDv4、UUIDv7 还是 ULID 当主键，真正在选的只有键宽和同一毫秒内有没有顺序。InnoDB 上一个写入者时递增键少近四成的页，四个写入者只剩两成、文本主键反而更差；按主键范围分片的库上递增变成写热点，按 hash 分布的库不看这一项。

两张明细表只共享半个唯一键，同层 JOIN 之后才聚合，分页接口那 40 秒慢查询就出在中间被 DISTINCT 压回去的那些行上；拆成三步后这组参数下结果逐行一致。

Confluent Kafka 的 topic 分区数按当前业务规模假设算了一轮，起步先按 12 个分区配置。

Java 25 跑在 Kubernetes 上，默认堆只用了 25%，CPU 节流的影响也比预期大，这几组实验数据和值得优先验证的配置项放在一起。

结合 Homelab 场景整理 Kubernetes 的 CPU requests/limits、CFS throttling、QoS 类别与节点压力驱逐机制，以及我当前采用的资源配置思路。