Cassandra运行约1小时无报错自动退出，该排查哪些内容？

这种没报错但cqlsh自动退出的情况确实挺闹心的，结合你的环境信息和给出的GC日志，我整理了几个可以排查的方向，你可以逐一试试：

• 检查系统OOM Killer日志：虽然Cassandra自身的日志没记录错误，但系统层面的OOM Killer可能在内存不足时直接杀掉进程，Cassandra根本没机会写错误日志。你可以查看/var/log/syslog或者执行dmesg命令，搜索oom-killer、java或者Cassandra关键词，看看有没有进程被强制终止的记录。毕竟你的系统给Cassandra的可用内存只有488MB，远低于官方推荐的最小1GB，很容易触发系统的内存回收机制。

• 调整cqlsh的超时配置：cqlsh本身有默认的超时设置，如果长时间和节点没有交互，可能会自动断开连接。你可以这么操作：

  1. 检查conf/cqlshrc文件（没有的话直接新建一个），添加以下配置：

     [connection]
     client_timeout = 36000  # 单位是秒，设置成10小时这样的长超时
     

  2. 或者启动cqlsh时直接指定超时参数：cqlsh --request-timeout 36000
     调整后观察是否还会自动退出。

• 实时监控Java堆内存与GC情况：从你给出的GC日志看，Old Gen的内存一直在缓慢增长（从64MB涨到69MB），虽然目前还没到临界值，但长期运行可能导致堆内存耗尽。你可以用jstat命令实时监控：

  jstat -gcutil $(pgrep java) 1000  # 每秒输出一次GC统计数据
  

  重点看Old Gen（输出里的O列）的使用率，如果持续上升接近100%，说明要么有内存泄漏，要么堆内存分配不足。结合你的系统内存，你可以调整conf/jvm.options里的JVM参数，比如把堆内存设置为-Xms200m -Xmx200m（别超过系统可用内存的一半，避免挤占系统资源）。

• 检查系统资源限制：Cassandra需要较高的文件描述符限制，Ubuntu默认的限制可能不够。你可以先执行ulimit -a查看当前用户的资源限制，重点看open files的值，官方推荐至少设置为100000。如果当前值过低，修改/etc/security/limits.conf文件，添加：

  cassandra soft nofile 100000
  cassandra hard nofile 100000
  

  保存后重启Cassandra服务，确保配置生效。

• 用nodetool检查节点状态：在cqlsh还没退出的时候，或者重启后立刻执行nodetool status，看看节点是否处于UN（正常可用）状态。另外，执行nodetool gcstats可以查看更详细的GC统计，看看是否有频繁的Full GC导致节点无响应，进而让cqlsh断开连接。

• 监控交换空间使用情况：虽然你有4GB交换空间，但频繁使用交换会让系统性能急剧下降，甚至可能导致进程被终止。执行free -h查看交换空间的使用率，如果Swap的used值持续增长，说明系统在依赖交换内存运行，这时候要么增加物理内存，要么调整JVM参数减少堆内存占用，尽量避免使用交换空间。

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