Golang chromedp爬虫突发connection reset by peer错误如何排查？

故障根因定位 #

从你提供的CloudWatch运行日志可以直接定位核心问题：

• 日志明确抛出pthread_create: Resource temporarily unavailable (11)报错，说明AWS线上运行环境的线程/进程资源被耗尽，Chrome启动时无法创建新线程直接崩溃退出
• 你观察到的connection reset by peer是Chrome崩溃后，chromedp尝试连接Chrome DevTools WebSocket接口时，内核直接返回RST包导致的衍生错误，并非问题根源
• 本地容器运行正常是因为本地测试环境的资源限制比AWS线上宽松，未触碰到线程数上限

修复方案 #

临时规避验证 #

先调高AWS部署环境的线程/进程数限制，快速验证问题：

• 若为EC2部署：修改/etc/security/limits.d/下的配置，调高nproc软、硬限制
• 若为容器部署：调整容器的pids_limit参数，移除不合理的pid上限配置
• 调整后重新部署程序，确认报错是否消失

根本问题修复 #

程序稳定运行2周才出现故障，本质是Chrome进程/线程资源泄漏导致的，需要调整代码逻辑：

• 检查chromedp使用逻辑，每次爬取任务结束后必须显式调用cancel()释放关联context，同时确保Chrome实例被正常终止，避免残留僵尸进程占用资源
• 配置chromedp启动参数，禁用不必要的功能降低线程开销，刚好也可以解决日志中media_stream_manager相关的崩溃问题：

opts := append(chromedp.DefaultExecAllocatorOptions[:],
    chromedp.Flag("headless", true),
    chromedp.Flag("disable-gpu", true),
    // 禁用媒体流功能，对应日志中media_stream_manager崩溃点
    chromedp.Flag("disable-media-stream", true),
    chromedp.Flag("no-sandbox", true),
    chromedp.Flag("disable-dev-shm-usage", true),
)

• 增加资源监控逻辑，定期统计当前运行的Chrome进程数、线程使用量，达到阈值时自动重启程序作为兜底机制

可选优化 #

如果爬取任务量较大，不要每次请求都创建新的Chrome实例，可以实现Chrome实例池复用已启动的Chrome进程，大幅降低线程/进程的创建销毁开销，从根源上降低资源耗尽的概率。

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