Asp.NetCore在CentOS网站卡死

最近碰到项目的网站在高峰期卡死的现象。刚开始以为是数据库问题导致的卡死，就排查和改了数据的设置。然后观察几天发现网站还是会在高峰期卡死，然后改了点网站设置，准备第二天观察一下，星期二竟然又没出现卡死了，为此理解为服务器虚拟机不稳定，服务器抽风，以为这事就这么完了。

然而星期三竟然又卡死了，于是马上连上vnp排查问题，由于前几次都没当回事，然后用户还急着用，当时就重启web站点解决了，不过倒是想好了下次再出问题排查步骤。

1.先用浏览器访问网站，看是加载静态资源卡死了还是请求后台卡死的，以此断定问题出在web还是web连接数据库上。
2.如果所有请求卡死那么问题出在web上。在shell里curl登录页面来判断是web卡死还是客户端和web服务器网络或端口不通。
3.如果curl通那么说明是web网络和端口问题。
4.如果curl不通那么就查看Linux进程信息（ps aux | grep imedicallis）。
5.如果进程也正常那么查看端口信息（lsof -i:端口）。

经过排查是端口一直等待Close_Wait。

说明服务器无法再开端口供服务器连接了，至此找到卡死原因了，无法打开端口给客户端，先重启web让客户使用。

先排查连数据的httpclient是不是用了IHttpClientFactory，因为dotnetcore本身的HttpClient存在连接释放问题。由于这块地方在开发时候就重点测试了，应该没问题，而且别的项目也没问题，程序代码问题可以排查。

然后百度一下别人是否有类似经验，找到如下：

立马用ulimit -n查看了下最大打开文件数，发现是1024，看来就是这个原因了。然后从别的项目拷了/etc/security/limits.conf文件，在dba指导下高峰期更新了这个配置，在最下面加上如下：

# End of file
* soft    memlock   -1
* hard    memlock   -1
* soft    rss       -1
* soft    rss       -1
* soft    nproc     65535
* hard    nproc     65535
* soft    nofile    65535
* hard    nofile    65535
* soft    stack     -1
* hard    stack     -1

然后执行sysctl -p使配置生效，执行完重启web站点是web用新配置启动。同时ulimit -a查看配置是否修改成功。

Last login: Fri Mar 24 17:27:46 2023 from 14.204.0.229
[root@iris142 ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63408
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63408
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[root@iris142 ~]# sysctl -p
[root@iris142 ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63408
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63408
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[root@iris142 ~]# 

按理并发打开文件到1024也够可以了，为了看看是不是确实是这个原因。又找到网站进程号，查看这个进程打开文件数。

[root@iris142 ~]# ps aux | grep imedicallis
root     12108  0.0  0.0 112708   980 pts/0    S+   21:02   0:00 grep --color=auto imedicallis
root     24757  0.1  1.9 23373708 310868 ?     S<sl Mar14  23:06 /usr/local/dotnet/dotnet /dthealth/app/dthis/imedicallis/iMedicalLIS.dll --urls https://*:1444
[root@iris142 ~]# 

[root@iris142 ~]# lsof -p 24757

发现网站一启动就打开了快900个文件，其中包括dotnetcore运行时的库和相关依赖和网站文件，那么这个1024在高峰期卡死就很正常了，稍微访问些东西就打开文件达到1024了。

Linux下一切皆文件，socket也是文件，所以在打开文件数到1024后无法开启新的网络

这OS挺坑的啊，主要当服务器，竟然默认打开文件限制这么小，基本web服务器都不够用啊，不知道怎么想的，醉了