gcore可在不中断Nginx服务前提下为运行中的worker进程生成内存快照，前提是进程状态正常、权限足够、core dump未被禁用，且需配合带调试符号的Nginx二进制用gdb分析调用栈与内存问题。
当 Nginx 出现疑似崩溃、卡死或 CPU/内存异常占用时，gcore 可以在不中断服务的前提下，为正在运行的 worker 进程生成内存快照（core dump），便于后续用 gdb 分析调用栈、内存泄漏或锁竞争等问题。关键前提是：Nginx 必须以调试符号编译（推荐使用官方 debug 版本或自行启用 --with-debug 编译），且系统允许生成 core 文件。
确认 Nginx 进程状态与权限
先定位目标 worker 进程 PID（避免对 master 进程操作）：
- 执行
ps aux | grep nginx，区分master process和worker process；通常 worker PID 是数字较大、用户为www-data或nginx的行 - 确保当前用户对目标进程有
ptrace权限（Linux 默认要求同用户或 root）。普通用户启动的 Nginx，需用同一用户或 root 执行gcore - 检查
/proc/sys/kernel/core_pattern是否允许写入（如设为/dev/null则会失败），临时可改回默认：echo "/tmp/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern
用 gcore 抓取指定 worker 的内存快照
假设目标 worker PID 是 12345，执行：
sudo gcore -o /tmp/nginx_worker_12345 12345- 成功后生成文件如
/tmp/nginx_worker_12345.12345（即 core dump 文件） - 若报错
Operation not permitted，常见于容器环境或启用了ptrace_scope：可临时关闭echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（仅调试用，勿长期保留）
用 gdb 分析 core 文件定位问题
需搭配带调试符号的 Nginx 二进制（如 nginx-debug 或自编译的 debug 版）：
- 确认 Nginx 二进制路径：
which nginx或查看ps输出中的完整路径（如/usr/sbin/nginx） - 运行：
gdb /usr/sbin/nginx /tmp/nginx_worker_12345.12345 - 进入 gdb 后输入：
bt full查看完整调用栈；info registers检查寄存器；thread apply all bt查所有线程栈（尤其适用于多线程模块或第三方模块引发的 hang） - 若怀疑内存问题，可用
info proc mappings结合x/20xg $rsp等命令查看栈内存布局
注意事项与替代建议
该方法不重启、不中断请求，但会短暂暂停目标 worker（毫秒级），生产环境慎用于高负载核心节点：
- 不要对 master 进程使用
gcore，它不处理请求，分析价值低 - Core 文件体积大（常达百 MB），请确保
/tmp或目标路径空间充足 - 若无法复现故障，可配合
systemd-coredump或配置nginx.conf中的worker_rlimit_core+ulimit -c unlimited实现自动崩溃转储 - 更轻量的初步排查可先用
strace -p PID -s 256 -T或lsof -p PID快速观察系统调用和句柄占用
