Symfony2应用随机挂起：调试工具及排查方法咨询

这种无错误日志、服务器指标正常但应用随机挂起的问题确实很棘手，结合你Symfony2+Docker的场景，我整理了一套排查工具和思路，一步步来定位问题：

• Symfony Profiler：虽然挂起时无法直接访问前端页面，但可以配置把Profiler数据持久化下来。修改config_prod.yml中的framework.profiler节点，开启enabled: true并设置dsn（比如指向本地文件或数据库），这样就能留存挂起前的请求细节——比如异常的数据库查询、耗时过长的服务调用、内存占用趋势等，帮你找到请求卡壳的环节。
• 增强Monolog日志配置：默认日志可能遗漏了关键上下文。调整Monolog的配置，把日志级别调到DEBUG，同时添加fingerprint处理器追踪同一个请求的全链路日志，还要记录请求ID、用户信息、参数等上下文数据。确保日志输出到容器持久化目录或外部日志服务，避免容器挂起后日志丢失。

直接看容器内的进程状态，能快速定位系统调用层面的阻塞：

• strace：当应用再次挂起时，用docker exec -it <容器ID> bash进入容器，找到Symfony对应的PHP-FPM进程（或CLI进程，如果是命令行触发的问题），执行strace -p <进程ID>跟踪系统调用。你能看到进程卡在了哪个环节——比如是在等待数据库连接、网络IO，还是某个文件锁。
• lsof：用lsof -p <进程ID>查看进程打开的文件描述符，检查是否有未关闭的数据库连接、文件句柄泄漏，或者是否在等待某个套接字的响应。
• PHP-FPM状态页：如果是用PHP-FPM运行的Symfony，修改PHP-FPM的pool配置，开启pm.status_path = /status，然后通过curl访问这个路径，查看进程状态、请求队列长度、处理时长等。挂起时如果有进程卡在非idle状态，或者请求队列堆积，就能直观发现问题。

很多时候挂起是内存泄漏导致进程僵死：

• 内置内存监控函数：在Symfony的关键控制器或服务中，插入memory_get_usage()和memory_get_peak_usage()的日志记录，跟踪每个请求的内存占用变化。如果发现某个请求的内存持续攀升直到触达PHP内存限制，那大概率是内存泄漏。
• valgrind（测试环境用）：在测试环境中，可以用valgrind --leak-check=full php bin/console server:run运行应用，或者针对PHP-FPM进程做内存泄漏检测。注意这个工具会大幅降低性能，绝对不要在生产环境直接使用。
• OPcache状态检查：如果启用了OPcache，通过phpinfo()或opcache_get_status()查看缓存状态，检查是否存在缓存失效、内存不足的情况——OPcache的异常也可能导致进程挂起。

如果应用涉及并发操作，死锁是常见诱因：

• 数据库死锁检测：如果用MySQL，开启innodb_print_all_deadlocks配置，死锁信息会写入MySQL错误日志；如果是PostgreSQL，查询pg_locks视图，查看是否有未释放的锁。数据库死锁会导致应用进程无限等待，进而表现为挂起。
• Symfony服务并发检查：排查应用中是否有共享资源（比如文件缓存、全局变量）未加锁的情况，或者异步任务（如Messenger组件）是否出现阻塞。用ps aux在容器内查看是否有大量处于阻塞状态的进程。

虽然服务器指标正常，但还是要排除容器层面的隐藏问题：

• Docker资源限制：用docker inspect <容器ID>查看HostConfig下的Memory、CpuShares等配置，确认容器是否有过低的内存限制——即使服务器整体内存充足，容器内存不足也可能导致PHP进程因OOM被杀死，你可以用宿主机的dmesg命令查看是否有OOM日志。
• 宿主机网络状态：用netstat -anp或ss -anp查看宿主机与容器的网络连接，检查是否有大量TIME_WAIT或ESTABLISHED状态的连接，排查是否存在网络阻塞。

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