周谈（2）- 管道写满导致程序阻塞

前言

在工作中，每周都会遇到一些问题，这些问题在大家工作中可能会有许多共性，于我也是一种经验的积累小结。我觉得花一些时间整理一下，跟粉丝读者们分享一下日常工作遇到的问题，这是一个很好的互动和文章分享的痛点。

这是第二篇, 下面看问题。

管道写满导致程序阻塞

最近有业务开发反馈他们在执行一个命令的时候，在命令行分页停留的时候，会导致他们数据面的程序挂住。

分析了一下原因， 命令行使用python的subprocess执行shell命令，读取shell的输出。在命令分页停留的时候，命令行就不会去读取输出，这就导致了输出的缓冲满了，命令程序阻塞了，然后此时那个数据面又在等待他的那个命令程序取读取数据，这样他的数据面也挂住了，^_^。主要原因就是管道已经被写满了，再调用write的时候，命令程序阻塞了。

在linux中，管道也是一个文件，一端读一端写，实际上管道就是一块内存缓存区，是有容量限制的。当管道满的时候：

O_NONBLOCK disable： write调用阻塞，直到有进程读走数据, 一般都是设置这个。
O_NONBLOCK enable：调用返回-1，errno值为EAGAIN

我们通过ulimit -a命令查看到的pipe size定义的是内核管道缓冲区的大小，这个值的大小是由内核设定的；而pipe capacity指的是管道的最大值，即容量，是内核内存中的一个缓冲区。

Keep:~ keep$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited

网上有许多程序测试管道的最大容量， 结果是65536。

总的来说，管道就像是水管，堵住了总有最大容量吧。然后，每次写入的大小也是有限制的,超过了不保证写入的原子性。分别对应 capacity 和 pipe size。

管道特性小结

读管道：

• 1. 管道中有数据，read返回实际读到的字节数。
• 2. 管道中无数据：
     (1) 管道写端被全部关闭，read返回0 (好像读到文件结尾)
     (2) 写端没有全部被关闭，read阻塞等待(不久的将来可能有数据递达，此时会让出cpu)

写管道：

• 1. 管道读端全部被关闭， 进程异常终止(也可使用捕捉SIGPIPE信号，使进程不终止)
• 2. 管道读端没有全部关闭：
     (1) 管道已满，write阻塞。
     (2) 管道未满，write将数据写入，并返回实际写入的字节数。

管道之前将sysrepo的时候有用到过，就是使用了它的特性。

更多

最近项目进内测了，作为平台支撑的开发，总是格外的忙。许多业务定位不了的问题，都要被拉着去定位，忙的连改bug的时间都没有了。

项目还有各种奇葩的指标需要去满足。什么Bug缺陷率需要达到多少，测试用例数目啊，各种cli命令汇总等待。还有一些详细设计变更要补充。说到底，就是缺人。要求有点高，外加钱没给到位，招聘不到合格的人，只能尽量压榨现有人员。貌似是工作这么些年以来最忙的一段时间了。

说实在的，我还有点怀念之前那公司的管理风格和氛围了，虽然流程缺失了许多，但没有那么多的条条框框。给你充分发挥的空间和时间，任务也不是那么的紧张，有自我充电的时间，肯花些时间就可以很容易的胜任工作。

行动，才不会被动!

欢迎关注个人公众号 微信 -> 搜索 -> fishmwei，沟通交流。