工业互联网安全态势感知平台遇到了大麻烦，因为3台物理机撑起来的Elasticsearch集群在TB级流式日志面前表现不佳。每台机器配32G内存、4核CPU和8TB机械盘，运行的是6.2.4版本的Elasticsearch，前端还用Kibana、Elasticsearch-head和自研监控系统做支撑。虽然看着挺稳，但实际效果却很差，数据写不进去，积压从缓存传到了Kafka，实时性完全没了。 后台日志里频繁出现RejectionException和连接超时的提示，查一下\_cat/tasks就知道了，单个Bulk任务动不动就10秒，而正常情况下应该在10ms以内。\_cat/thread_pool?v里的write队列疯狂拒绝请求。这时候看硬件资源指标CPU只有60%左右，内存也只是70%满，瓶颈根本不在资源上，而在于写入模型和线程池规模严重不匹配。 团队为了应对每天几十GB的新增日志量，决定同时试试横向扩容和纵向优化。横向优化就是加节点、分片、副本，见效快但成本高；纵向优化是压榨单台机器性能，治标也治本；业务侧还得减少冗余字段、批量合并事件从源头减负。最后拍板先纵向榨干这台老机器再说。 给索引缓存翻了一倍，原来默认10%现在是20%，还给了个最小值512MB。内存缓存满了才会触发段写盘，提前腾出空间就能减少I/O风暴。把Fielddata Cache也从10%扩到了20%，让聚合查询先吃内存再用磁盘。机械盘加上高吞吐网络I/O容易飙升，默认1秒一次的心跳太敏感了，就把检测超时设成120秒、重试次数设为6次、间隔设为30秒。 机械盘随机I/O每秒几十次就封顶了，多线程合并反而让磁盘忙不过来，就把后台合并线程数设成1个。线程池也重新排兵布阵：Bulk池负责入口设置了16个线程和1000的队列；Index池负责段写入和调度也设置成同样参数；Search池保证查询不卡留给5个线程和500的队列。 结果重启后write rejected立马归零，Bulk任务耗时跌回了毫秒级；积压数据连夜清空，Kafka消费速度终于超过了生产速度。晚上过去平台就回到了“数据不落地”的舒适区。虽然还有查询性能、元数据吞吐这些战场要打，但“先治标再治本”的办法被验证可行——只要持续看指标、用配置试错，老集群也能在工业数据洪流里继续冲锋。