今天生产环境下部署在Linux服务器上的站点突然无法访问,日志中出现大量的这样的错误:
Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -24 EMFILE too many open files
这个问题与在.net core中遇到的奇怪问题:内存与线程数一直增长是同一个问题。
估计是TCP连接过多引起的
问题的根源是在构造函数中用(且只能用)同步方式调用System.Net.Dns.GetHostAddressesAsync()异步方法。
相关链接:
* Dns.GetHostAddressesAsync is blocking a ThreadPool thread
* 解决 .NET Core 中 GetHostAddressesAsync 引起的 EnyimMemcached 死锁问题
* .NET Core中遇到奇怪的线程死锁问题:内存与线程数不停地增长
最终采取的解决方法见:
libuv出来的错误,估计是linux下的KestrelServer有bug。
提交issues呗
ulimit -n看下是 1024吗?如果是的话需要修改 /etc/security/limits.conf文件,在末尾增加
* soft nofile 数字
* hard nofile 数字。
或者直接运行下面的
echo -ne "
* soft nofile 65536
* hard nofile 65536
" >>/etc/security/limits.conf
然后重新登陆
ulimit -n 的结果是 65535
@dudu:
该站点的最大并发数有可能达到这个数值吗?
@Zachary_Fan: 当时的异常情况可能造成达到了这个数值
@dudu: 那要么继续放大这个值再观察看看是否还有错误,要不然得加机器了~
@Zachary_Fan: 升级到 ASP.NET Core 1.1 之后没再出现这个问题
@dudu: 嗯,不过理论上如果真的是并发数达到这个值的话,应该和升级没有关系,还会继续有这个问题 。。。不过祝您好运~
我网上找了篇文章给您参考下~
http://blog.sina.com.cn/s/blog_5f66526e0100xl5t.html
@dudu: 是的,我最上面回复让您执行的语句就是配置这个设置的。如果并发数的确达到目前设置的65535的话,要么继续放大这个配置,或者在负载均衡加机器了。