最近碰到项目的网站在高峰期卡死的现象。刚开始以为是数据库问题导致的卡死，就排查和改了数据的设置。然后观察几天发现网站还是会在高峰期卡死，然后改了点网站设置，准备第二天观察一下，星期二竟然又没出现卡死了，为此理解为服务器虚拟机不稳定，服务器抽风，以为这事就这么完了。
然而星期三竟然又卡死了，于是马上连上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服务器都不够用啊，不知道怎么想的，醉了