Python 踩坑之旅进程篇其五打不开的新文件

1.1 踩坑案例

长期运行的 daemon 进程或者 socket 测试类进程, 经常遇到的坑是:

IOError: [Errno 24] Too many open files

即进程遇到 IO 错误, 无法打开更多的文件.

1.2 填坑和分析

一般从两个方面入手:

1.2.1 从程序优化入手

检查文件打开是否遵循了"谁打开谁关闭"原则
文件是否存在关闭泄露

a. 谁打开谁关闭是个普适的原则:

只有逻辑设计者自己最熟悉
- 哪些文件 FD 需要一直维持打开状态
- 哪些文件直到某个事件发生后关闭
短暂的文件读写打开推荐使用 pythonic 的 with statement

# with 语法会在生命周期后自动关闭打开的文件 FD
with open('xxxx_path.file', 'w') as fhandle:
    fhandle.dosth()

b. 检查文件 FD 是否存在泄漏

系统设计阶段一般会预估系统总体可打开的 FD 情况. 当出现如下情况时可能出现了泄漏 BUG

外围监控系统发现该进程 FD 大量突破了设计预估
打开 FD 增长趋势异常
- 一般随着业务增加, FD 会线性增长, 但有限度和规律
- 如果增长曲线不停的出现陡峭增长且在业务低峰期也如此可能出现了泄露

Python 基础库 CUP 提供对进程打开 FD 的支持, 详见示例代码.

1.2.2 从资源软硬限入手

了解系统的资源软硬限制
检查进程可打开的 FD 是否突破了系统限制
- 长期运行的 daemon 进程尤其注意

以 Centos 6.3 Linux 系统为例, 查看 /etc/security/limits.conf 获得系统软硬限资源

* soft nofile 10240
* hard nofile 10240

其中, 用户不能突破系统的硬线 hard nofile limit.

用户也可以通过 shell 命令 ulimit -n 来限定该 shell 启动的所有进程的 nofile

当然非 root 用户是不能突破系统硬线的
用户为了进程控制, 可以设定 nofile 更小

ulimit -a 可以查看当前用户被设定的限制, 示例:

[test@agent1 ~]$ ulimit -a
core file size          (blocks, -c) 0
.......
open files                      (-n) 10240
.....
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

1.4.1 技术关键字

Open FD
资源 Soft limit / Hard limit

下期坑位预告

PyDaemon 进程长什么样

文章来源

作者持续更新的 cnblogs: https://www.cnblogs.com/mythmgn/

作者持续更新的 Github:

https://github.com/mythmgn/awesome_py_traps

Life is short. We use Python.