进程的 PID 不停在变，要么是这些进程在不停地重启，要么就是全新的进程，这无非也就两个原因：
第一个原因，进程在不停地崩溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控系统自动重启了。进程本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的 CPU。
第二个原因，这些进程都是短时进程，也就是在其他应用内部通过 exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束，很难用 top 这种间隔时间比较长的工具发现。
一般当进程非正常退出时，会生成一个core文件，这个文件是进程猝死时内存的转储文件，也称为core dump。
core文件生成时间长，会导致业务进程一直挂着，会导致业务中断。
1.gdb查看core文件，关注信号 SIGSEGV
看是由什么信号触发
常见的段错误信号 4, 7, 11
每个信号都有一个名字和编号，这些名字都以“SIG”开头，例如“SIGIO”， “SIGCHLD”等等。信号定义在signal.h投文件中，信号名都定义为正整数。
具体的信号名称可以使用kill -l来查看信号的名字以及序号，信号是从1开始编号的，不存在0号信号。kill对于信号0有特殊的应用。
表：term：信号终止进程；core：进程产生核心存储文件并退出；ignore：忽略该信号；stop：信号停止了进程；cont：信号恢复了一个已停止的进程
| 名 称 | 信 号 值 | 描 述 | SUSv3 | 默认 |
|---|---|---|---|---|
| SIGABRT | 6 | 中止进程 | ● | core |
| SIGALRM | 14 | 实时定时器过期 | ● | term |
| SIGBUS | 7（SAMP = 10） | 内存访问错误 | ● | core |
| SIGCHLD | 17（SA=20，MP=18） | 终止或停止子进程 | ● | ignore |
| SIGCONT | 18（SA=19，M=25，P=26） | 若停止则继续 | ● | cont |
| SIGEMT | undef（SAMP=7） | 硬件错误 | term | |
| SIGFPE | 8 | 算术异常 | ● | core |
| SIGHUP | 1 | 挂起 | ● | term |
| SIGILL | 4 | 非法指令 | ● | core |
| SIGINT | 2 | 终端中断 | ● | term |
| SIGIO | 29（SA=23，MP=22） | I/O时可能产生 | ● | term |
| SIGPOLL | ||||
| SIGKILL | 9 | 必杀（确保杀死） | ● | term |
| SIGPIPE | 13 | 管道断开 | ● | term |
| SIGPROF | 27（M=29，P=21） | 性能分析定时器过期 | ● | term |
| SIGPWR | 30（SA=29，MP=19） | 电量行将耗尽 | term | |
| SIGQUIT | 3 | 终端退出 | ● | core |
| SIGSEGV | 11 | 无效的内存引用 | ● | core |
| SIGSTKFLT | 16（SAM=undef，P=36） | 协处理器栈错误 | term | |
| SIGSTOP | 19（SA=17，M=23，P=24） | 确保停止 | ● | stop |
| SIGSYS | 31（SAMP=12） | 无效的系统调用 | ● | core |
| SIGTERM | 15 | 终止进程 | ● | term |
| SIGTRAP | 5 | 跟踪/断点陷阱 | ● | core |
| SIGTSTP | 20（SA=18，M=24，P=25） | 终端停止 | ● | stop |
| SIGTTIN | 21（M=26，P=27） | 后台进程组从终端读取 | ● | stop |
| SIGTTOU | 22（M=27，P=28） | 后台进程组向终端写 | ● | stop |
| SIGURG | 23（SA=16，M=21，P=29） | 套接字上的紧急数据 | ● | ignore |
| SIGUSR1 | 10（SA=30，MP=16） | 用户自定义信号1 | ● | term |
| SIGUSR2 | 12（SA=31，MP=17） | 用户自定义信号2 | ● | term |
| SIGVTALRM | 26（M=28，P=20） | 虚拟定时器过期 | ● | term |
| SIGWINCH | 28（M=20，P=23） | 终端窗口尺寸发生变化 | ignore | |
| SIGXCPU | 24（M=30，P=33） | 突破对CPU时间的限制 | ● | core |
| SIGXFSZ | 25（M=31，P=34） | 突破对文件大小的限制 | ● | core |
Kill -9一般不会生成core
信号15是主动杀
信号6一般是abort
信号11 是内存引用问题。（比如：指针为空）
2.分析日志
如果有 core，则搜日志 “Signal captured” 或 “Assert”;
网络问题中，比较容易出现core问题。
3.不生成core的原因
没有core: 说明他们自身没有产生core的机制。
core生成原理，如果信号没有捕获到，也不会生成；还有一种可能性是不是信号量阻塞了。
原因可能如下：
1、没有开启 core：ulimit -c 如果显示为0是没有开启 core 的。
2、没配 core_pattern 路径。
4.gdb看不到core堆栈信息
解决方法：
gdb
(gdb) set sysroot /tmp/lib
(gdb) set solib-search-path /tmp/lib:/lib64
(gdb) file [二进制文件]
(gdb) core /tmp/corefiles/core-***
t a a bt查看所有线程堆栈
https://blog.csdn.net/liubangbo/article/details/84841181
https://blog.csdn.net/pcj_888/article/details/106882370
data 目录下面的 diag 目录下找下有没有 blackbox 目录，里面也有 trace 栈
参考链接：
1.blog.csdn.net/shaovey/article/details/2744487
Linux下core文件调试方法
2.andyniu.iteye.com/blog/1965571
linux下生成core dump文件调试方法及设置
3.信号概述