这是一个创建于 1390 天前的主题，其中的信息可能已经有所发展或是发生改变。
/var/log/messages
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice,task=java,pid=88959,uid=1000
oom_reaper: reaped process 88959 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
只能看到 pid，而且是 java，但是不知道具体是那个 java，（ vm 上好多个 java 进程的）
 |
1
julyclyde 2021-01-25 16:59:34 +08:00
这事你只能认倒霉
下次最好放到 systemd 管理，然后 task_memcg 那里就会显示一个 slice 名字了 |
 |
2
lff0305 2021-01-25 20:15:01 +08:00 via Android
十多年以前，解决一个类似问题的方案是，从 java cp 多个副本，java1 java2 等等等等，然后修改启动脚本，用自己的 javan 来启动。被杀了就看从 Java n 反查出来哪个服务再看日志等等来分析
|
 |
3
qfdk 2021-01-25 20:18:22 +08:00
不是有个 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=文件路径 好像有个这个东西，炸了之后会有个 jvm dump
|
 |
5
chenshun00 2021-01-25 20:32:09 +08:00
@qfdk 你这个是 OOM，这种属于操作系统的 OOM Kill 是不行的，从虚拟机迁移到 K8s 特别多.. , 关键是自己的技术水平还解决不了它
|
 |
6
chendy 2021-01-25 21:07:48 +08:00
@chenshun00 容器的话，起码能看到哪个容器被干了，k8s 的话也能帮忙自动重启，问题还好办一些
|
|
7
qfdk 2021-01-25 22:27:19 +08:00
@chenshun00 这样的话可以考虑用 agent 了 弄个 elk 的 apm 看一下就是了。 里面也能知道 containerId 之类的。这样的东西感觉加内存应该可以处理，有时候内存太小里面出现的问题有点儿玄学。
|
Select Language