问题描述
使用 captcha_method = "personal"(nodriver 模式)时,浏览器启动失败后的重试机制会不断创建新的 Chrome 进程和临时 profile 目录,但旧进程不会被清理,导致进程和磁盘空间持续增长。
复现场景
远端 Mac 上观察到:
- 11 个不同的 Chrome profile 同时运行(
launch_retry_profile_* 和 fresh_browser_profile_*)
- 每个 profile 约 6 个进程,共 66 个 Chrome 进程
src/tmp/ 目录下累积了 28,931 个临时 profile 目录,占用 167MB
- 正常应该只有 1 个
browser_data_nodriver 主 profile
日志证据
浏览器启动不断重试,每次失败都创建新 profile:
09:10 - launch_retry_profile_b929umsk → 失败 → 创建 launch_retry_profile_ukiz78yr
10:00 - launch_retry_profile_ukiz78yr → 失败 → 创建 launch_retry_profile_3jwj2a7n
11:10 - launch_retry_profile_3jwj2a7n → 失败 → 创建 launch_retry_profile_z4k6pgfh
每次重试都 spawn 新 Chrome 进程,旧的未被杀掉,形成进程堆积。
根因分析
_is_retryable_browser_launch_error() 检测到启动失败后,创建新 launch_retry_profile_* 目录重试
- 重试时没有杀掉上一次的 Chrome 进程,旧进程继续运行
- 临时 profile 清理依赖 6 小时 TTL(
PERSONAL_RUNTIME_PROFILE_STALE_TTL_SECONDS),清理不及时
- 形成雪球效应:越多失败 → 越多进程 → 资源越紧张 → 更多失败
建议修复
- 在创建新 retry profile 前,先杀掉当前 browser 对象关联的 Chrome 进程
- 降低临时 profile 清理 TTL,或在重试时同步清理上一次的 profile
- 限制最大重试次数或最大并发 Chrome 实例数
环境
- macOS (远端 Mac mini, headed 模式)
- captcha_method = "personal"
- nodriver 模式
- Chrome 148.0.7778.x
临时解决方案
手动清理:
# 清理残留 Chrome 进程
pkill -9 -f 'Google Chrome'
# 清理临时 profile 目录
rm -rf ~/Prog/flow2api/src/tmp/launch_retry_* ~/Prog/flow2api/src/tmp/fresh_browser_*
# 重启服务
问题描述
使用
captcha_method = "personal"(nodriver 模式)时,浏览器启动失败后的重试机制会不断创建新的 Chrome 进程和临时 profile 目录,但旧进程不会被清理,导致进程和磁盘空间持续增长。复现场景
远端 Mac 上观察到:
launch_retry_profile_*和fresh_browser_profile_*)src/tmp/目录下累积了 28,931 个临时 profile 目录,占用 167MBbrowser_data_nodriver主 profile日志证据
浏览器启动不断重试,每次失败都创建新 profile:
每次重试都 spawn 新 Chrome 进程,旧的未被杀掉,形成进程堆积。
根因分析
_is_retryable_browser_launch_error()检测到启动失败后,创建新launch_retry_profile_*目录重试PERSONAL_RUNTIME_PROFILE_STALE_TTL_SECONDS),清理不及时建议修复
环境
临时解决方案
手动清理: