一次nginx文件打开数的问题排查处理

现象：nginx域名配置合并之后，发现consul-template无法完成nginx重载，然后发现需要重启nginx，才能让配置生效。

注意：下次哪个服务有报错，就看重启时所有日志输出，各种情况日志输出。不要忽略细节。很多时候其实已经看到了问题，却没有深入查看问题。

查看进程最大打开文件个数

#cat /proc/31146/limits|grep “Max open files”

Max open files            1024                 4096                 files

# cat /usr/lib/systemd/system/openresty.service

[Unit]

[Service]

LimitNOFILE=655350

[Install]

#

consul-template无法重载，是因为进程本身无法重载，进程无法打开文件了

查看日志报错：有打开太多文件数

这里查看的，不是那个进程所能打开的最大个数

找到进程id,查看进程可以打开的最大个数，虽然nginx配置了worker可以打开很多个文件，但是也没有设置master进程打开文件个数

master进程是systemd启动，systemd启动的进程需要设置打开文件大小个数，新增配置项LimitNOFILE=655350，把数弄大点

重启之后，查看进程最大支持打开文件个数，已经被修改了

多次重载nginx,可以看到旧的子进程在关闭，新的子进程在启动代替它

systemd 启动配置openresty.service，配置的是master打开的文件个数，nginx.conf里面设置的是worker打开的文件个数

=====

参考信息如下：

nginx重载，/bin/kill -s HUP 不生效

在Nginx中，

/bin/kill -s HUP

命令通常用于重新加载Nginx的配置文件，而不是挂起（suspend）Nginx进程。如果你发现这个命令没有生效，可能是由以下几个原因造成的：

1. 错误的进程ID：确保你发送HUP信号的进程ID（PID）是正确的。你可以通过
   
ps

   命令查找Nginx的主进程ID。

   通常，你会看到类似
   
nginx master process

   的行，后面跟着的就是主进程的PID。

2. 权限问题：你可能没有足够的权限来发送信号给Nginx进程。确保你具有发送信号到该进程的权限，或者使用root用户来执行该命令。

3. Nginx进程未运行：确保Nginx服务正在运行。你可以使用
   
systemctl status nginx

   （对于使用systemd的系统）或
   
service nginx status

   （对于使用SysVinit的系统）来检查Nginx的状态。

4. Nginx配置文件有错误：如果Nginx的配置文件存在语法错误，
   
nginx -s reload

   或
   
/bin/kill -s HUP [nginx_pid]

   可能不会生效，因为Nginx无法重新加载一个无效的配置。你可以使用
   
nginx -t

   来测试配置文件的语法是否正确。

5. Nginx不是通过init系统启动的：如果Nginx不是通过init系统（如systemd或SysVinit）启动的，那么它可能不会响应HUP信号。确保Nginx是通过标准的init系统服务来管理的。

6. SELinux或AppArmor安全策略：如果你的系统启用了SELinux或AppArmor这样的安全模块，它们可能会阻止进程之间的信号传递。检查相关的安全策略或日志文件以确认是否有相关的限制。

7. 其他系统级限制：有些系统级的限制（如cgroups、资源限制等）可能会阻止进程接收或处理信号。

为了解决这个问题，你可以尝试以下步骤：

• 使用正确的Nginx进程ID重新发送HUP信号。
• 确保你具有发送信号所需的权限。
• 检查Nginx的状态和日志文件，确认它是否正在运行且没有错误。
• 使用
  
nginx -t

  测试Nginx配置文件的语法是否正确。
• 如果可能的话，尝试通过init系统（如
  
systemctl reload nginx

  ）来重新加载Nginx配置。
• 检查SELinux或AppArmor的安全策略，确保它们没有阻止信号传递。
• 如果以上步骤都无法解决问题，考虑重启Nginx服务（但请注意，这会导致短暂的服务中断）。

nginx报错 open() “_error.log” failed (24: Too many open files)

Nginx 报错 “open() “_error.log” failed (24: Too many open files)” 意味着 Nginx 进程尝试打开的文件数量超过了系统或用户级别的限制。在 Linux 系统中，每个进程和每个用户都有打开文件数量的限制。

要解决这个问题，你可以采取以下几个步骤：

1. 检查当前限制：
   
   你可以使用
   
ulimit -n

   命令来查看当前 shell 会话中打开文件的数量限制。然而，Nginx 进程的限制可能由系统或用户级别的限制设置，而不是由 shell 会话设置。

   为了查看 Nginx 进程的实际限制，你可以查看
   
/proc/[nginx_pid]/limits

   目录中的文件，其中
   
[nginx_pid]

   是 Nginx 主进程的 PID。或者，你可以使用
   
cat /proc/[nginx_pid]/limits | grep 'Max open files'

   命令。

2. 增加用户级别的限制：
   
   如果你确定问题是用户级别的限制，你可以修改
   
/etc/security/limits.conf

   文件，添加或修改类似下面的行来增加打开文件的限制：

   或者，只为运行 Nginx 的用户（如
   
www-data

   ）设置限制：

   注意：修改这些限制后，需要重启 Nginx 或重新登录用户才能生效。

3. 增加系统级别的限制：
   
   如果你发现系统级别的限制也很低，你可能需要修改
   
/etc/sysctl.conf

   文件（或相应的 sysctl 配置位置），增加
   
fs.file-max

   的值。例如：

   修改后，需要运行
   
sysctl -p

   或重启系统来应用新的设置。

4. 优化 Nginx 配置：
   
   确保你的 Nginx 配置中没有导致打开过多文件的设置。例如，避免不必要的日志记录、优化缓存设置等。

5. 检查文件描述符泄漏：
   
   如果 Nginx 进程持续打开新的文件描述符而没有关闭它们，这可能是资源泄漏的迹象。使用工具如
   
lsoft

   或
   
strace

   可以帮助你诊断这种情况。

6. 重启 Nginx：
   
   在修改限制或修复潜在的问题后，重启 Nginx 以确保更改生效。

7. 监控和日志：
   
   监控 Nginx 进程的文件描述符使用情况，并定期检查日志文件以获取可能的线索。

请注意，在修改系统或用户级别的限制之前，最好先了解你的系统环境和需求，以避免意外的问题。如果你不确定如何操作，最好咨询系统管理员或有经验的开发人员。

查看进程最大打开文件个数

要查看Linux系统中进程的最大打开文件个数限制，你可以使用

ulimit

命令（针对当前shell会话）或查看

/proc

文件系统下的特定进程信息。但是，

ulimit

通常显示的是当前shell会话的限制，而不是特定进程的限制。

要查看特定进程（例如Nginx的主进程）的最大打开文件数限制，你可以直接读取

/proc/[pid]/limits

文件，其中

[pid]

是进程的PID。但是，这个文件的内容可能不太容易直接读取，因为它包含了多个字段和限制。

一个更简单的方法是使用

cat

命令结合

grep

来提取与打开文件数（nofile）相关的行：

将

[pid]

替换为你要查询的进程的PID。这将显示类似以下内容的输出：

这里，

1024

是软限制（soft limit），表示进程在达到这个限制时会收到警告，但可以继续运行；

4096

是硬限制（hard limit），表示进程不能打开超过这个数量的文件。

如果你只是想快速查看某个用户的默认打开文件数限制（这通常也是新进程的默认限制），你可以使用

ulimit -n

命令（在用户的shell中执行）：

这将显示当前shell会话的打开文件数软限制。请注意，这不一定反映Nginx或其他进程的实际限制，除非这些进程在当前shell会话中启动。

最后，如果你想要修改这些限制，你可能需要编辑

/etc/security/limits.conf

文件（对于用户级别的限制）或使用

sysctl

命令修改系统级别的

fs.file-max

参数（这控制整个系统的文件描述符数量上限）。但是，在修改这些设置之前，请确保你了解它们的影响，并在可能的情况下先在测试环境中进行验证。

ulimit生效命令

在Linux系统中，

ulimit

命令用于设置或报告当前shell会话的资源限制。这些限制包括打开文件的最大数量、进程可以创建的最大数量、栈大小、CPU时间等。然而，

ulimit

的设置仅对当前shell会话及其子进程有效，不会影响已经运行的进程或其他用户的shell会话。

查看当前限制

要查看当前shell会话的打开文件数限制，可以使用：

设置资源限制

要设置打开文件的最大数量限制（例如，设置为4096），可以使用：

这将对当前shell会话及其所有后续启动的子进程生效。但是，它不会影响已经运行的进程或其他用户的shell会话。

持久化ulimit设置

由于

ulimit

的设置仅对当前shell会话有效，因此如果你希望在系统启动时或在新的shell会话中自动应用这些设置，你需要将它们添加到用户的shell配置文件（如

.bashrc

、

.bash_profile

、

.zshrc

等）中。

例如，在Bash shell中，你可以将

ulimit

命令添加到

~/.bashrc

文件的末尾：

然后，为了使更改生效，你需要重新加载

.bashrc

文件或启动一个新的shell会话：

或者，你可以简单地关闭并重新打开终端。

注意事项

• 修改
  
ulimit

  设置可能会影响程序的正常运行，特别是如果设置的限制低于程序所需的值。因此，在修改这些设置之前，请确保你了解它们的影响。
• 如果你想要修改系统级别的资源限制（例如，
  
fs.file-max

  ），你需要使用
  
sysctl

  命令或编辑相应的系统配置文件（如
  
/etc/sysctl.conf

  ），并可能需要重启系统或重新加载内核参数才能使更改生效。
• 对于Nginx等长时间运行的服务，通常建议在系统启动脚本或init.d脚本中设置适当的资源限制，以确保服务在启动时具有正确的限制。这可以通过在启动脚本中添加
  
ulimit

  命令或使用其他机制（如systemd的
  
LimitNOFILE

  指令）来实现。

修改nginx进程 Max open files

要修改Nginx进程的最大打开文件数（Max open files），你需要做的是调整Nginx运行用户的文件描述符（file descriptor）限制。这通常涉及到修改系统级别的设置和用户级别的限制。

1. 修改系统级别的文件描述符限制

首先，你可能需要修改系统级别的文件描述符限制，这可以通过编辑

/etc/sysctl.conf

文件来实现。在文件中添加或修改以下行：

然后，运行

sysctl -p

来使更改生效，或者重启系统。

2. 修改用户级别的文件描述符限制

Nginx通常以特定的用户身份运行（如

nginx

、

www-data

等）。你需要为这个用户设置文件描述符的限制。这可以通过修改

/etc/security/limits.conf

文件来实现。在文件中添加或修改类似以下行：

这里的

*

表示所有用户，但你也可以为特定的Nginx用户（如

nginx

）设置限制。

soft

是警告限制，当达到这个限制时，系统会给用户一个警告，但仍然允许其继续运行。

hard

是硬限制，当达到这个限制时，系统将不允许用户打开更多的文件。

3. 使用systemd管理Nginx服务

如果你的系统使用systemd来管理Nginx服务，你也可以在Nginx的systemd服务单元文件中设置资源限制。编辑Nginx的service文件（通常位于

/etc/systemd/system/

或

/lib/systemd/system/

目录下），添加或修改

LimitNOFILE

选项：

修改后，重新加载systemd配置并重启Nginx服务：

4. 验证设置

要验证设置是否生效，你可以检查Nginx进程的

/proc/[pid]/limits

文件（将

[pid]

替换为Nginx主进程的PID），或者运行以下命令来查看Nginx用户的限制：

如果输出与你在

limits.conf

或systemd服务单元文件中设置的限制相匹配，那么设置就已经生效了。

worker_rlimit_nofile 51200

在Nginx的配置文件中，

worker_rlimit_nofile

指令用于设置工作进程（worker process）可以打开的最大文件描述符数量。这个设置对于Nginx服务器来说非常重要，因为它直接关联到Nginx能够处理的并发连接数。

在Nginx的配置文件（通常是

nginx.conf

或者包含在

nginx.conf

中的某个include文件）中，你可以设置

worker_rlimit_nofile

的值，例如：

这条指令告诉Nginx，每个工作进程最多可以打开51200个文件描述符。

请注意，

worker_rlimit_nofile

的设置值应该根据你的系统资源和Nginx的使用情况进行调整。如果你设置的值太高，可能会导致系统资源耗尽；如果设置得太低，可能会限制Nginx的性能。

此外，你还应该确保系统级别的限制（通过

sysctl

和

/etc/sysctl.conf

设置）和用户级别的限制（通过

/etc/security/limits.conf

设置）允许Nginx达到这个值。如果系统或用户级别的限制低于你在Nginx配置中设置的值，那么Nginx将无法使用超过这些限制的文件描述符数量。

最后，在修改这些设置后，你需要重新加载或重启Nginx以使更改生效。如果你使用的是systemd管理Nginx服务，可以使用以下命令来重新加载Nginx配置：

或者重启Nginx服务：