系统重启后ngix reload不生效原因分析

系统重启后ngixreload不生效原因分析

系统重启后ngix重装不起作用的原因分析

这是一个很少见的困扰我很久的问题。虽然这个问题很简单，但是要找到根本原因还是要花很多时间。现在分享分析过程如下。

前提:你需要对Linux系统启动流程、Nginx进程启动流程、进程跟踪有一定的了解。

1.Nginx重装过程分析；

查阅官网文档，结合Nginx源代码分析，大致可以得出如下结论:重装过程中进行了以下 *** 作。

1.检查配置是否正确。

相当于nginx-t

2.打开日志文件

相当于nginx-s重新打开

因为有很多日志文件，所以需要打开多个文件。

3.重新监听插座

相当于nginx

这一步会初始化很多东西，重点是哈希表。

4.关闭旧的工作进程

相当于nginx-s退出

二、nginx流程分析

1，先了解nginx的两个流程。

主进程，根用户打开，接收信号并管理工作进程。

Worker进程，由nginx用户打开，worker进程，负责处理http请求。

2.starce跟踪了主进程号，在进程中执行nginx-sreload，发现卡在了检查日志文件中。

主进程跟踪，因为重装进程是系统向nginx主进程发送HUP信号。

#starce-p2298

......

open("/data/wwwlogs/access.XXX.XXX.XXX.log"，O_WRONLY|O_CREAT|O_APPEND，0644)=-1EMFILE(打开的文件太多)

写(808，"2016/02/1709:50:22[emerg]2298"...,124)=124

......

3.根据提示，找到进程的系统限制文件。

主流程限制

#cat/proc/2398/limits

限制软限制硬限制单位

最大cpu时间无限制无限制秒

最大文件大小无限制无限制字节

最大数据大小无限制无限制字节

最大堆栈大小10485760无限字节

最大核心文件大小0无限字节

最大常驻集无限无限字节

最大进程数127015127015进程

最大打开文件数10244096个文件

最大锁定内存6553665536字节

最大地址空间无限制无限制字节

最大文件锁定数量无限数量无限锁定

最大挂起信号127015127015个信号

最大msgqueue大小819200819200字节

最高优先级00

最大实时优先级00

最大实时超时无限制用户

工作进程限制

#cat/proc/2300/limits

限制软限制硬限制单位

最大cpu时间无限制无限制秒

最大文件大小无限制无限制字节

最大数据大小无限制无限制字节

最大堆栈大小10485760无限字节

最大核心文件大小0无限字节

最大常驻集无限无限字节

最大进程数127015127015进程

最大打开文件数409600409600文件

最大锁定内存6553665536字节

最大地址空间无限制无限制字节

最大文件锁定数量无限数量无限锁定

最大挂起信号127015127015个信号

最大msgqueue大小819200819200字节

最高优先级00

最大实时优先级00

最大实时超时无限制用户

补充错误日志:

2016/02/1710:48:05【通知】47386#0:信号流程开始

2016/02/1710:48:05[emerg]2298#0:open()"/data/wwwlogs/access_XXX.XXX.XXX.log"失败(24:打开的文件太多)

第三，解决方案

1、修改限制条件

一般来说，从以下三个方面来调:

第一:nginx.conf参数化编程和设置

Worker_rlimit_nofile:限制单个工作进程打开的最大文件数:

在线配置没有问题。

worker_rlimit_nofile409600

第二:系统级检查和设置。

即/etc/etc/security/limits.conf的配置和修改请参考Linux系统资源限制总结。

在线配置没有问题。

*软nofile655350

*硬文件655350

第三，内核级检查和设置:

设置fs.file的大小-最大值:

线上配置比较大。

fs.file-max=6553600

注意:file-max的默认值大约是系统内存的10%(系统内存是以kb为单位计算的)

2、验证生效

结果上面的配置都是前期配置的，但是重启服务器发现的主进程的限制并没有修改。但登录服务器后，无论终端ulimit-n查看还是关闭nginx的主进程，重启nginx都会生效。因此，可以推断

问题可能出在linux系统的启动过程中，也就是说nginx的主进程启动时，上述限制配置并没有生效。后来查阅资料发现，restrictions.conf配置只有在系统启动后执行登录才会生效，所以需要调整顺序。

根据实际情况，系统启动过程如下:

1.读取/etc/inittab以读取默认级别。假设:默认水平读数为3。

2.执行初始化系统脚本/etc/rc.d/rc.sysinit来初始化脚本。

3.然后执行/etc/rc.d/rc脚本。

4.执行/etc/rc.d/rc.local脚本，这是启动过程中启动的最后一个脚本。

最后，将执行/bin/login来登录用户。至此，/etc/profile，~/。bash_profile，~/。巴沙尔等。在系统启动过程完成之前不会执行。此时ulimit-n找到的值并不是nginx进程启动时的值。

当用户默认登录时，limits.conf配置文件将生效，这晚于nginx进程的开始。要使配置在此之前生效，您需要补充如下配置:

cat/etc/rc.local

Ulimit-HSn655350(注意应该在nginx启动之前执行)

/usr/local/nginx/sbin/nginx

第四，补充优化

主要原因是相关参数被放大了。

1、内核优化

net.ipv4.tcp_max_tw_buckets修改是为了减轻内核负担，iptable本身对内核性能有影响。

#ss-an|awk“{print$1}”|sort|uniq-c|sort-rn

ESTAB街15415号

12979时间-等待

1961年芬-等待-2

501FIN-WAIT-1

234最后确认

32同步接收

11听

3关闭

1个同步发送

1个州

1关闭-等待

在线修改配置如下:

net.IPv4.TCP_max_tw_buckets=18000

2、nginx优化

主哈希表和其他配置已经过优化。有以下散列表。

可以添加服务器名称哈希

可以添加Map_hash

Types_hash就够了。

请求标题不考虑

Variables_hash就够了

在线修改配置如下:

服务器名称哈希最大大小512000；

服务器名称哈希桶大小64；(默认)

map_hash_max_size204800

map_hash_bucket_size64(默认)