ffmpeg工具wav转换成MP3使用方式不当造成线程数激增问题

一. 问题描述

年前腊月二十九，接到客户方业务反馈，生产系统数据部分未进入系统，有数据丢失的现象。排查应用系统日志发现，报错：ubable to create new native thread. 如下图：

二. 从系统配置层面排查：

无法创建更多线程，出现此问题的原因是应用系统进程内，创建的线程数量超过了操作系统限制，具体超过了哪一个限制配置，需要根据配置数值一一确认：

1. 出现报错后，应用系统所在服务器的总线程数：

2. 出现报错后，应用系统进程的总线程数：

可以排除，当前用户下有其他进程影响线程数的可能

3. 系统全局总线程数配置：vim /proc/sys/kernel/threads-max

4. 系统全局PID数值限制：vim /proc/sys/kernel/pid_max

5. 单个程序所能使用内存映射空间的数量限制：vim /proc/sys/vm/max_map_count

单个vm能开启的最大线程数是这个值的一半,可以通过 cat /proc/PID/maps查看目前使用的映射数量

6. 某个用户的默认的总任务数：vim /etc/systemd/logind.conf

7. 每个用户设置的最大任务数限制：find /sys/fs/cgroup -name “pids.max”

无

8. ulimit 中 max_user_process 配置：ulimit -a

至此的结论：发现系统有关的配置限制都很大，不至于出现超过的情况，出现问题时，应用系统的线程数是3545，此数值在系统线程数合理范围内，并且系统中使用到多线程的逻辑，均是线程池管理的线程，并且不涉及cachedThreadPool，均是FixedThreadPool，所以进一步怀疑，可能还是超过了操作系统内的某个限制配置。

三. 进一步寻找系统配置：

1. vim /proc/pid/cgroup：查看某个进程所属cgroup组

既然在上述操作系统层面的配置下，超过限制的可能性很小，进一步想到了linux的cgroup机制。cgroup多用于虚拟容器场景下，比如docker，用于管理系统资源分配与限制情况。

之前有了解到，centos发行版内核中，也有cgroup的机制使用，但是并没有用户级或者进程级的线程数限制，但是此生产环境使用的是suse sp3发行版操作系统，于是翻看了suse sp3发行版手册，发现suse中的cgroup机制有引入pids.max文件进行用户级或者进程级的线程数限制，于是，进一步排查配置：

发现，应用系统的进程所属user-601.slice组

2. 进一步查询user-601.slice 的线程数限制配置：cat /sys/fs/cgroup/pids/user.slice/user-601.slice/pids.max

发现，应用进程所属用户，最多可以创建线程数为12288，这个数值会比上述操作系统层面的限制小一些，突破这个限制的可能性大很多，但是3545相比12288也有很大差距，于是卡住在了这一步。。。

3. 经过一天时间的摸索调研，发现如果是触发了cgroup的pids.max限制，操作系统日志会有明确错误记录：/var/log/messages

发现上图的报错，说明报错无法创建线程时，确实是超过了当前用户cgroup的线程数限制配置。

四. 排查超过12288限制的原因：

1. 应用进程内部线程数为什么会有这么多？通过代码反复分析、测试环境反复复现也没有能够得到答案，于是，迫于无奈，向生产环境申请加入线程数监控脚本，检测当前应用进程，如果进程内部线程数超过5000，则打印所有的线程详细信息，终于，得到以下重要信息：

应用系统总线程数7626，其中ffmpeg线程总数4074

根据打印的pid, ppid信息分析，发现一个wav文件转换成MP3时，开辟了65路线程并发转换，至此，分析出了原因：MP3转换总并发路数配置是200, 极端情况下200*65 > 12288 ，所以会超cgroup限制。

五. 关于ffmpeg

机器是64核机器，所以一个ffmpeg进程开辟了65个线程进行转换。

六. 解决方案

对一个wav文件来说，时长5分钟左右，所以根本不需要开辟这么多线程进行转换，ffmpeg可以通过指定 -thread n 参数来控制转换时开辟的线程并发数。