单节点CnosDB容器宕机无异常日志？OOM与业务日志时间差排查

核心原因 #

CnosDB服务宕机的根本原因是宿主机OOM（内存不足）杀死了CnosDB的tokio-runtime-worker进程，日志时间差异由以下常见情况导致：

• 时区不一致：容器内部时区与宿主机时区不匹配，导致CnosDB日志时间戳和dmesg显示时间基于不同时区基准。比如容器用UTC时区、宿主机用东八区时，两者时间会有8小时差值，看起来日志时间晚于OOM事件，实际是时区转换的错觉。
• 进程延迟崩溃：OOM杀死单个tokio工作进程后，CnosDB的Tokio运行时会尝试重启工作进程，暂时维持服务。但如果内存压力持续存在，后续会有更多工作进程被OOM杀死，最终导致主进程因依赖资源耗尽而崩溃，此时才停止日志输出，因此日志最后一条时间晚于首次OOM事件时间。
• 日志缓冲延迟：CnosDB的日志输出可能存在内存缓冲，未立即写入磁盘。直到进程崩溃前，缓冲区才被刷新到磁盘，导致磁盘上的最后日志时间晚于实际OOM事件发生时间。

验证与排查步骤 #

• 检查容器与宿主机时区一致性：
  进入CnosDB容器执行命令：date，同时在宿主机执行date，对比两者时区和时间是否一致。若不一致，可通过挂载宿主机时区文件修正：

  docker run -v /etc/localtime:/etc/localtime:ro ... # 追加到原有启动参数后
  

• 排查OOM后的进程状态：
  查看宿主机系统日志（如journalctl -k --since="2024-01-20"或/var/log/syslog），确认OOM事件后是否有CnosDB相关进程的后续崩溃记录，是否存在多次OOM触发的情况。
• 调整内存相关配置：
  1. 给Docker容器设置合理内存限制：使用--memory和--memory-swap参数限制容器内存使用，避免无限制占用宿主机内存。
  2. 调整CnosDB配置文件中的内存参数：比如降低tskv压缩的并发度，或设置查询内存上限，避免压缩或查询过程中内存占用过高。
• 监控tskv压缩的资源消耗：
  观察压缩任务执行时的内存占用情况，若压缩过程内存飙升，可配置在业务低峰期触发压缩，或调整压缩算法的内存占用参数。

内容的提问来源于stack exchange，提问作者Baker X