CnosDB进程因Signal 11终止，疑与磁盘耗尽相关的技术问询

云上老周

2026-7-9

问题

CnosDB进程收到Signal 11（段错误）信号被终止，该进程以单例模式通过Docker启动，持续运行约两周后被操作系统杀死。查看磁盘发现/data1分区已100%占用，但未出现预期的“磁盘空间不足”日志。已提供容器日志、启动命令、数据加载及查询脚本、dmesg日志，询问：是否因磁盘耗尽导致进程被终止？

分析与结论

Signal 11的核心指向：Signal 11是段错误，本质是进程非法访问内存，和OOM Killer发送的Signal 9（强制杀死）不同，但磁盘耗尽可能是触发段错误的间接诱因。
磁盘满的潜在影响路径：
- 若/data1是CnosDB容器挂载的数据目录，磁盘满后，CnosDB写入WAL、数据文件或日志时会失败。如果程序对写失败的异常处理逻辑存在缺陷，可能触发内存访问异常，进而抛出Signal 11。
- 磁盘耗尽还可能导致系统页缓存异常，干扰进程正常的内存读写操作，引发段错误。
无“磁盘空间不足”日志的可能原因：
- CnosDB的日志写入操作本身因磁盘满而失败，导致相关告警日志无法生成。
- 容器日志采集机制在磁盘满的情况下出现故障，未捕获到CnosDB内部的磁盘告警日志。
验证方向：
- 检查dmesg日志，若存在文件系统层面的“空间不足”错误（如no space left on device），同时伴随CnosDB进程的段错误记录，可确认磁盘满是诱因。
- 确认容器启动命令中数据目录的挂载配置，确保CnosDB确实在使用/data1分区的存储空间。
- 若开启了核心转储，分析CnosDB的core文件，定位段错误的触发点是否与磁盘IO相关。