Bug：Too many open files【ulimit限制】

本文主要是介绍Bug：Too many open files【ulimit限制】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Bug：Too many open files

今天在开发某个下载功能时，发现文件总是下载到250多个程序就挂掉，同时会打崩服务器，查看错误日志发现报：too many open files.

思路：根据错误信息可以知道打开的文件数过多，立马想到系统自身有一个ulimit限制（限制打开的文件数），可能是因为自身并发数设置过高且ulimit配置的允许打开文件数数值过低。

1 排查思路

1.1 查看ulimit数值

以Mac系统为例。

# 执行命令查看ulimit限制
launchctl limit
#第一列为项的名称，第二列为软件限制，第三列为硬件限制

在这里插入图片描述

如果是ulimit配置太小，可以通过下面命令修改
注意：如果数值设置的太高会影响系统的稳定性。

sudo launchctl limit maxfiles 1024 unlimited
#修改完后，open files的限制就到1024了

我将文件描述符修改到1024后，发现文件下载到1024左右程序就会卡死，可以确定和ulimit数没有关系。

1.2 查看程序并发数

查看是否是程序的并发数设置的太多（线程数或协程数），如果自身电脑打开的程序或者应用过多且并发数设置的过多，会导致某一段时间，打开的文件数超过ulimit的限制。

后来查看代码，发现协程数为5，对于该系统来说并不算高

1.3 查看文件流是否关闭

因为程序是下载功能，所以需要读取服务端的文件，这个时候就需要考虑是否是打开的文件流没有关闭导致文件句柄一直没有释放。

# 查看进程号
ps -ef | grep downloader
# 根据进程id查看进程占用的文件句柄
sudo lsof -p 30794
# 查看所有已建立或者listen状态的连接
sudo lsof -i -P | grep -i "listen\|established"

执行上面命令后发现我程序一直占用这Socket没有释放，这个时候就基本可以确定是代码某处打开的文件流没有关闭。

经过review代码，排查发现是在GetS3Object的时候没有对object的Body做close操作。添加上后，问题解决。

	object, err := client.GetObject(context.TODO(), &s3.GetObjectInput{Bucket: aws.String(bucketName),Key:    aws.String(key),})defer object.Body.Close()

2 解决

①修改系统ulimit参数值

以Mac系统为例。

# 执行命令查看ulimit限制
launchctl limit
#第一列为项的名称，第二列为软件限制，第三列为硬件限制

在这里插入图片描述

如果是ulimit配置太小，可以通过下面命令修改
注意：如果数值设置的太高会影响系统的稳定性。

sudo launchctl limit maxfiles 1024 unlimited
#修改完后，open files的限制就到1024了

②修改程序并发数

降低线程或协程数

③review代码是否有io流未关闭

我的问题是因为在获取S3对象时，忘记对object.Body做close操作

=object, err := client.GetObject(context.TODO(), &s3.GetObjectInput{Bucket: aws.String(bucketName),Key:    aws.String(key),
})
defer object.Body.Close()