Python并发请求报OSError解决方法

Python高并发请求时频繁报OSError（如“Too many open files”或“Invalid argument”），根源往往不是代码逻辑错误，而是系统文件句柄耗尽或socket参数异常；解决需双管齐下：先通过ulimit、limits.conf和systemd配置持久化提升Linux/macOS系统级文件描述符限制（推荐设为65536），Windows用户则需谨慎调整注册表或迁移到WSL；再配合Python侧优化——合理使用Session复用连接、设置连接池上限（如aiohttp的TCPConnector）、引入asyncio.Semaphore限流、确保响应体及时关闭，避免资源泄漏；记住：不查清ulimit -n就盲目改代码，只会事倍功半。

OSError 通常不是并发库本身的错，而是系统资源耗尽的信号——特别是文件句柄（file descriptor）用光了。 Python 的 requests、aiohttp、urllib 等底层都依赖操作系统分配 socket 和临时文件句柄；并发量一高，OSError: [Errno 24] Too many open files 或 [Errno 22] Invalid argument（尤其在重用连接或设置超时参数异常时）就会冒出来。先调系统限制，再调代码逻辑，顺序不能反。

查当前系统文件句柄限制是多少

不查清楚就改，容易白忙活。Linux/macOS 下直接运行：

ulimit -n

这个值是当前 shell 会话的软限制，一般默认是 1024。但实际能用多少，还受硬限制和系统级配置约束。继续查：

ulimit -Hn  # 硬限制
cat /proc/sys/fs/file-max  # 全局最大可分配句柄数

如果 ulimit -n 返回 1024，而你启动了 2000 个并发请求，失败就是必然的——每个连接至少占 1~2 个句柄（socket + 可能的 DNS 缓存 fd），还没算日志、临时文件等。

临时提高 ulimit 值（开发/调试用）

仅对当前终端生效，适合快速验证是否是句柄不足导致的 OSError：

• 先提硬限制（需要 root）：sudo ulimit -Hn 65536
• 再提软限制：ulimit -Sn 65536
• 然后运行你的 Python 脚本，比如 python main.py

注意：该设置不会影响已启动的进程，只对后续在该 shell 中启动的进程有效；且重启终端就失效。

永久修改 Linux 文件句柄限制

要让 Python 服务（如用 systemd 启动的爬虫或 API 网关）稳定跑高并发，必须持久化配置：

• 编辑 /etc/security/limits.conf，追加两行（替换 your_user 为实际用户名）：
  your_user soft nofile 65536
your_user hard nofile 65536
• 确保 pam_limits.so 已启用：检查 /etc/pam.d/common-session 是否含 session required pam_limits.so
• 如果是 systemd 服务（比如用 systemctl start myapp 启动），还需在 service 文件里显式设置：
  [Service]
LimitNOFILE=65536

改完需重新登录用户或重启 systemd 服务才生效。别漏掉最后一步，很多人卡在这儿。

Python 侧配合优化：别光靠堆句柄

系统限制放宽只是基础，代码不收敛连接，照样崩：

• 用 requests.Session() 复用连接，禁用 Connection: close，避免每请求新建 socket
• aiohttp 中务必用 ClientSession 配合 connector=TCPConnector(limit=100, limit_per_host=30) 控制并发连接池大小
• 避免无节制 asyncio.create_task()，用 asyncio.Semaphore(50) 限流
• 检查是否有未关闭的响应体：resp.close() 或用 async with session.get(...) 自动清理
• Windows 用户注意：ulimit 不生效，得改注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems 里的 Windows 字符串值，把 -c 1024 改成 -c 65536（风险较高，建议优先换 WSL）

最常被忽略的一点：OSError [Errno 22] 在高并发下有时不是路径问题，而是 socket 超时参数传了负数或 nan，比如误把 timeout=-1 传给 socket.settimeout() —— 这种错不会报明确提示，只在外层抛 Invalid argument，得结合 strace 或 lsof 看系统调用入参。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。