今天早上打开流量统计页面时，显示应用错误页面，还以为是应用程序崩溃了。检查日志后发现是 SQL server 无法连接。接下来开始排查 SQL server 连接问题。
具体问题
所有应用程序服务都无法连接到 SQL server，使用数据库管理工具去连接 SQL server 实例也无法成功，报错如下：
Connection reset ClientConnectionId:df9ade99-1fab-47f8-89ec-aab0b40fbfae
排查过程
1、首先检查 SQL server 实例是否启动，确认实例是启动状态。
我的机器是 Linux 系统，SQL server 的运行是通过系统服务来控制，使用以下命令检查服务状态：
sudo systemctl status mssql-server
输出如下
● mssql-server.service - Microsoft SQL Server Database Engine
Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-12-23 17:05:23 CST; 1 months 8 days ago
Docs: https://docs.microsoft.com/en-us/sql/linux
Main PID: 2076382 (sqlservr)
Tasks: 153
Memory: 7.8G
CGroup: /system.slice/mssql-server.service
├─2076382 /opt/mssql/bin/sqlservr
└─2076625 /opt/mssql/bin/sqlservr
可以看到我的 SQL server 服务状态为 active (running)，说明实例是启动状态。
2、接下来检查 SQL server 的监听端口，确认端口是否正确监听。
使用以下命令检查监听端口：
sudo netstat -tulnp | grep sqlservr
输出如下：
tcp 0 0 127.0.0.1:1431 0.0.0.0:* LISTEN 2457585/sqlservr
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN 2457585/sqlservr
tcp 0 0 127.0.0.1:1434 0.0.0.0:* LISTEN 2457585/sqlservr
tcp6 0 0 ::1:1431 :::* LISTEN 2457585/sqlservr
tcp6 0 0 :::1433 :::* LISTEN 2457585/sqlservr
tcp6 0 0 ::1:1434 :::* LISTEN 2457585/sqlservr
可以看到，系统监听了 1431、1433、1434 三个端口，说明实例是正常监听的。
3、检查防火墙设置，确认防火墙没有阻止 SQL server 端口。
我使用的是 UFW 防火墙，检查防火墙规则如下：
sudo ufw status
输出如下：
Status: active
可以看到防火墙的状态是 active，但是没有任何规则，说明防火墙没有阻止任何端口。
4、检查 SQL server 日志，确认没有其他错误信息。
SQL server 的日志文件位于 /var/opt/mssql/log 目录下，查看最新的错误日志：
sudo cat /var/opt/mssql/log/errorlog | tail -n 10
输出如下：
2026-01-31 10:34:18.29 Server Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.
2026-01-31 10:34:18.30 Server Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.
从日志中我们可以很明显的看到有错误信息，错误码为 17300，状态为 16，17300 错误是 SQL server 内部错误，通常表示资源已经耗尽，SQL server 现在无法再运行新任务。日志中还显示 SQL server 当前正处于精简模式，连格式化错误信息都无法做到。
解决方法
根据 SQL server 错误日志中的信息，确认是 SQL server 资源耗尽导致无法连接。接下来尝试配置 SQL server 的内存使用限制，防止 SQL server 占用过多内存资源。
由于 SQL server 在 Linux 系统上运行会默认使用系统的 80% 内存，如果系统中还有其他占用内存较大的服务，就会导致 SQL server 资源耗尽，因申请不到内存而无法连接。
直接使用以下命令配置 SQL server 最大内存使用为 4GB：
sudo /opt/mssql/bin/mssql-conf set memory.maxservermemory 4096
配置完成后，重启 SQL server 服务：
sudo systemctl restart mssql-server
这里可能会卡住，因为使用 systemctl 重启服务时，会等待服务完全启动后才返回。而且 systemctl 是发送 SIGTERM 信号来重启服务的，而 SQL server 内部已经没有资源来处理 SIGTERM 信号，所以会卡住。
这是我们需要强制结束 SQL server 进程，然后再启动服务：
sudo killall -9 sqlservr
sudo systemctl start mssql-server
重新启动服务后，等待几分钟让 SQL server 完全启动，这时候可以再打印一下 SQL server 的内存使用情况，确认内存使用已经限制在 4GB 以下。
sudo systemctl status mssql-server
● mssql-server.service - Microsoft SQL Server Database Engine
Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2026-01-31 10:53:35 CST; 29min ago
Docs: https://docs.microsoft.com/en-us/sql/linux
Main PID: 2457219 (sqlservr)
Tasks: 143
Memory: 4.1G
CGroup: /system.slice/mssql-server.service
├─2457219 /opt/mssql/bin/sqlservr
└─2457585 /opt/mssql/bin/sqlservr
然后使用数据库管理工具再次尝试连接 SQL server，连接成功，问题解决。