问题发现
某一次线上API突然访问报错，于是检查日志，发现存在大量的Too many open files的错误，继续跟踪，发现这些错误是日志在打开文件时出现的。
跟踪
最开始想到的是多个进程打开一个文件可能会造成文件打开数过多，但实际API只开启了4个进程，且每一个使用到文件的地方都已经关闭，因此排除文件描述符泄漏的问题。那么除了打开文件以外，有没有可能是其他占用导致的文件描述符不够呢，众所周知，Linux中万物皆文件，对于API这种网络应用来说，TCP连接数也同样会很多，想到这，我立马使用lsof命令查看文件描述符占用情况。
先使用ps命令查出某个gunicorn进程的PID
ps -ef | grep gunicorn
然后查看其中一个gunicorn进程的文件描述符情况
lsof -p | grep TCP | wc -l
结果发现一个进程所打开的TCP连接符就高达1000多个，且大部分都是3306端口，即myslq连接非常多。但问题来了，即便存在大量的TCP连接，它的数量也并没有超过1024个，而通过之前的设置，即已经配置/etc/security/limit.conf中的文件描述符打开数为65535个，那么为什么文件描述符打开数达到1024就已经报错呢
supervisor的限制
为了验证我的文件描述符限制修改是否生效，我使用ulimit -n命令查看当前文件描述符限制，的确是65535，与我配置的值一致，这就很奇怪了，1024远远没有达到65535，且这个数字明显就是默认的值，这说明我的配置没有对进程生效？显然Linux不可能有这样的BUG，我突然想到除了可以查看全局的ulimit之外，还可以查看进程本身的相关信息，而已经打开的进程会将信息存储在以PID号为命名的文件夹中，于是
cat /proc//limits
可以发现，进程的
Max open files的软限制为1024，硬限制为4096，与全局设置并不一致，为什么会这样，我陷入了沉思。我突然想到，在开发环境进行测试的时候，并没有出现过这样的问题，而代码都是同一套，那么是不是启动方式有什么区别呢，在开发的时候，API是采用前台启动的，而正式环境则是使用supervisor，那么问题很明显了，一定是supervisor的某些设置限制了其管理的进程的文件描述符，经过查证，果然在supervisord.conf配置中有一行minfds，表示进程可以打开的文件数
那么只需要将其设置成65535，问题就可以解决，至此，真相大白
问题又出
本以为事情解决，可以告一段落了，可没想到没过多久，API又出现了不能访问的问情况，而这一次，日志中不再是文件描述符打开过多的错误了，而是出现了如下错误
sqlalchemy.exc.TimeoutError: QueuePool limit of size 500 overflow 100 reached, connection timed out, timeout 30
难道是数据连接池的大小设置的不够吗，我又将连接池的上限设置到了2000，因为我用的是flask-sqlalchemy，因此只需要将SQLALCHEMY_POOL_SIZE设置成2000即可。经过设置之后，暂时解决了问题，可过了一段时间之后，它居然又报出连接池超限的错误，而我们的API显然不可能真的有如此高的并发，肯定是有连接泄漏的问题存在，可我已经将SQLALCHEMY_COMMIT_ON_TEARDOWN设置为True，而该行配置表示在每次请求之后会自动断开连接
真相大白
经过查阅flask-sqlalchemy的更新日志，发现它在v2.0以上版本将配置SQLALCHEMY_COMMIT_ON_TEARDOWN给移除掉了，因此设置该值已经不再起作用，解决办法就是显式地在每一次请求结束后断开连接，于是我利用钩子去做
@app.teardown_request
def teardown_request(exception):
"""在每次结束请求前清理掉mysql连接"""
if exception:
db.session.rollback()
db.session.remove()
结果仍然不行，随后我又仔细观察一下代码，发现定义模型的地方使用了sqlalchemy，而flask中却又是使用flask-sqlalchemy进行调用，因此我怀疑这个钩子中释放的连接是否跟模型中的sqlalchemy是同一个呢，经过调试打印两者的内存地址，果然，钩子每次释放的连接并不是模型的，至此，本次问题真正真相大白了，而解决办法也很简单，将flask-sqlalchemy替换成sqlalchemy即可，不要混用，代码如下
engine = create_engine(get_mysql_info(),
pool_size=webconfig.SQLALCHEMY_POOL_SIZE,
max_overflow=webconfig.SQLALCHEMY_MAX_OVERFLOW,
pool_recycle=webconfig.SQLALCHEMY_POOL_RECYCLE,
pool_timeout=webconfig.SQLALCHEMY_POOL_TIMEOUT,
pool_pre_ping=True,
convert_unicode=True)
db_session = scoped_session(sessionmaker(autocommit=False,
autoflush=False,
expire_on_commit=False,
bind=engine))
Base.query = db_session.query_property()
使用db_session去替换所有使用到db.session的地方即可