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

目录

• 1.1 踩坑案例
• 1.2 填坑和分析
  • 1.2.1 从程序优化入手
  • 1.2.2 从资源软硬限入手
  • 1.4.1 技术关键字
• 下期坑位预告

代码示例支持
平台: Centos 6.3
Python: 2.7.14
代码示例: 菜单 - 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 进程长什么样

---

Life is short. We use Python.