python里面的error log 完全没被打印，只显示了 6233 已杀死。看大家的例子，推测大概率是因为内存问题，但是要去确认。系统 out of memory, 那么此进程被系统的oom killer杀死。
先到这个路径 下 /proc/sys/vm ，看了配置，有三个跟oom相关的。oom_kill_allocating_task 、panic_on_oom，oom_dump_tasks ，取值分别是0,0,1。
参考大家的博客。
oom_kill_allocating_task 是一个控制在内存耗尽时是否结束那个造成内存耗尽的任务的开关。默认值为 0，表示 OOM Killer 会去扫描完整的任务列表，用启发式算法选一个进程来结束。通常被结束的进程是一个流氓任务内存大户。如果 oom_kill_allocating_task 的值不为 0，哪个任务申请内存的操作造成了内存耗尽，就把那个任务干掉。这样可以避免扫描任务列表这种昂贵的操作。
panic_on_oom，这是一个决定内存耗尽时是否触发内核错误的开关。默认值为 0，内存耗尽时内核让 OOM Killer 去干掉几个内存流氓，让系统继续干活。如果开关值为 1，那么内存耗尽时触发内核错误。然而在多 CPU 的机器上又是另外一番情景，没用过这种机器就不说了。如果开关值为 2，就算仅仅是一个 cgroup 里面发生了内存耗尽，整个系统都 panic 了。据说 1 和 2 这两个开关值是用来给集群做 failover 用的。
理论上，按照上述配置，OOM 发生的时候，系统不会发生 kernel panic，OOM Killer 会出来干活，而且是在启发式黑魔法的加持下机智的干活。
但是如果把系统搞挂了，貌似是，OOM 发生的时候，内核已经没有足够的资源去做扫描任务列表这种事情，然后整个系统就不可用了。
最后 看到有人说 用这几个命令。确定了确实是out of memory .
dmesg | egrep -i -B100 'killed process'
egrep -i 'killed process'/var/log/messages
egrep -i -r 'killed process'/var/log或:
journalctl -xb | egrep -i 'killed process'
https://blog.jamespan.me/2015/06/06/oom-killer-down
https://my.oschina.net/sukai/blog/654712?p=1
