Nginx中的TCP超时

Question

我正在Proxmox集群上运行大约60个uses服务器(使用KVM)。VM正在运行Debian 11的最新版本，他们使用nginx，不同版本的PHP和MariaDB。我遵循一个基础设施-作为代码-的方法，所有的服务器，除了一些例外，在我们的基础设施，如jitsi是由ansible提供的，因此几乎相同。我主持标准的Typo3安装以及更复杂的应用程序，通常是用Laravel开发的。不久前，我开始在CheckMK中为我们的基础设施和客户的项目配置活动检查(这些检查使用了Nagios的插件，名为check_http)，这意味着可以从外部访问。

在此之后，我开始以每天一到两次的频率获得超时错误，这些错误似乎是随机分布在我使用活动检查监视的二十台服务器上。起初，我认为这只是假阳性，但上周五在吉西会议上发生了这一事件，并由一位同事向我报告。我检查了nginx的日志，并在Checkmk无法到达服务器的确切时间内找到了以下条目，即不到一分钟(每次检查之间的时间，下一次检查总是为负值，意味着没有错误)，而且可能只有几秒钟。造成这个问题的原因是什么，我该如何解决呢？你有什么建议，我可以如何复制，然后进一步分析问题吗？

Checkmk-错误消息：

摘要连接到地址195.34.XXX.XXX和端口443:连接拒绝详细信息HTTP关键-无法打开TCP套接字

Checkmk-恢复-消息：

HTTP :HTTP/1.1200OK- 0.008秒响应时间中的59404字节

Nginx错误日志：

2022/09/16 11:18:42 警报 3212994#3212994：*2590打开插座#18

2022/09/16 11:18:42 警报 3212994#3212994：*2494打开插座#15

2022/09/16 11:18:42 警报 3212994#3212994：*2533打开插座#16

2022/09/16 11:18:42 警报 3212994#3212994：*2534打开插座#17

2022/09/16 11:18:42 警报 3212994#3212994：*2591打开插座#20

2022/09/16 11:18:42 警报 3212994#3212994：*2573打开插座#24

2022/09/16 11:18:42 警报 3212994#3212994：*2532打开插座#10

2022/09/16 11:18:42 警报 3212994#3212994：*3230打开套接字#28

2022/09/16 11:18:42 警报 3212994#3212994：*2467打开插座#19连接15

2022/09/16 11:18:42 警报 3212994#3212994：*2535打开插座#21

2022/09/16 11:18:42 警报 3212994#3212994：*3233打开插座#27

2022/09/16 11:18:42 警报 3212994#3212994：*2771打开插座#30

2022/09/16 11:18:42 警报 3212994#3212994：*2770打开套接字#29

2022/09/16 11:18:42 警报 3212994#3212994：*3234打开插座#22

2022/09/16 11:18:42 警报 3212994#3212994：*3229打开插座#11连接26

2022/09/16 11:18:42 警报 3212994#3212994：*3231打开套接字#32

2022/09/16 11:18:42 警报 3212994#3212994:中止

2022/09/16 11:20:19 错误 3295994#3295994：*153个上游超时(110:连接超时)

您诚挚的

斯特凡·马尔特·舒马赫

Answer 1

这可能是由于太少的“最大数量的开放文件软限制”。我看到Debian中的默认值从65536改为1024。这对nginix来说是不够的。通过键入以下命令，在控制台中验证这一点：

ulimit -n

要确保nginx使用的限制，请键入以下命令，检查它的PID值：

 ps aux |grep nginx

您可以获得以下几行：

www-data  148105  0.0  0.1  59100  5492 ?        S    Feb09   0:00 nginx: worker process

取一个进程(第二列)的PID，然后：

cat /proc/[PID]/limits
     
cat /proc/148105/limits # in this example

搜索行：

Max open files            8192                 8192                 files

如果得到1024而不是8192，那么在nginx.conf文件(nginx.conf)的开头(主部分)添加以下行：

worker_rlimit_nofile 8192;

你可以去看。用更大的数字。最后，重新启动ngnix守护进程，并使用上述过程检查新值。