1.Web****服务介绍
1.1Apache经典的Web****服务端
Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发
目前经历了两大版本分别是1.X和2.X
其可以通过编译安装实现特定的功能
Apache prefork****模型
预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024
每个子进程有一个独立的线程响应用户请求
相对比较占用内存，但是比较稳定，可以设置最大和最小进程数
是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景
优点：稳定
缺点：每个用户请求需要对应开启一个进程,占用资源较多，并发性差,不适用于高并发场景Apache worker****模型
一种多进程和多线程混合的模型
有一个控制进程，启动多个子进程
每个子进程里面包含固定的线程
使用线程程来处理请求
当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求，
由于其使用了线程处理请求，因此可以承受更高的并发
优点：相比prefork 占用的内存较少，可以同时处理更多的请求
缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超
时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用（该问题在
prefork模式下，同样会发生）
Apache event****模型
Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll)
每个进程响应多个请求，在现在版本里的已经是稳定可用的模式
它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题
（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）event MPM中，会有一个专门的线程来管理这些keepalive类型的线程
当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场
景下的请求处理能力
优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep
alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放
缺点：没有线程安全控制
2.Nginx-高性能的Web****服务端Nginx是由1994年毕业于俄罗斯国立莫斯科鲍曼科技大学的同学 伊戈尔**·赛索耶夫**为俄罗斯著名搜索网站
rambler.ru开发的，开发工作最早从2002年开始，第一次公开发布时间是2004年10月4日，版本号是
0.1.0
2019年3月11日F5 与 NGINX达成协议,F5 将收购 NGINX 的所有已发行股票，总价值约为 6.7 亿美元。
6.7亿美金约合44.97亿人民币,nginx核心模块代码长度198430（包括空格、注释），所以一行代码约为
2.2万人民币
官网地址 www.nginx.org
Nginx历经十几年的迭代更新（https://nginx.org/en/CHANGES）， 目前功能已经非常完善且运行稳
定，另外Nginx的版本分为开发版、稳定版和过期版，nginx以功能丰富著称，它即可以作为http服务
器，也可以作为反向代理服务器或者邮件服务器能够快速的响应静态网页的请求
支持FastCGI/SSL/Virtual Host/URL Rwrite /Gzip / HTTP Basic Auth/http或者TCP的负载均衡(1.9版本以
上且开启stream模块)等功能，并且支持第三方的功能扩展。
天猫 淘宝 京东 小米 163 新浪等一线互联网公司都在用Nginx或者进行二次开发
基于Nginx的工作场景：
**3.服务端I/O流程**
I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，
是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的
I/O请求数量为单位，I/O请求通常为读或写数据操作请求。
一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用
户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而
是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说I/O就是把数据从
内核空间中的内存数据复制到用户空间中进程的内存当中。
服务器的I/O类型
磁盘I/O
网络I/O : 一切皆文件,本质为对socket文件的读写磁盘****I/O
磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是HTML 文件或者图片，然后内核通过
相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内
存，如果是比较大的数据也需要等待时间
网络****I/O
网络通信就是网络协议栈到用户空间进程的IO就是网络IO
不论磁盘和网络****I/O
每次I/O，都要经由两个阶段：
第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长
第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短
4.I/O****模型
4.1 I/O****模型相关概念
同步/异步：关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状
态的通知。
同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事
情是否处理完成
异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态
阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂
起，干不了别的事情。
非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完
成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情。
5网络I/O****模型
阻塞型、非阻塞型、信号驱动型、异步、复用型、
5.1阻塞型I/O****模型（blocking IO）
阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞
用户线程通过系统调用read发起I/O读操作，由用户空间转到内核空间。内核等到数据包到达后，然
后将接收的数据拷贝到用户空间，完成read操作
用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个I/O请求的过程中，用户线
程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够
优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源
缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销
较apache 的preforck使用的是这种模式。
同步阻塞：程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进
程将一直等待并不再接受新的请求，并由进程轮询查看I/O是否完成，完成后进程将I/O结果返回给
Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看I/O是否完成，这种
方式简单，但是比较慢，用的比较少。5.2非阻塞型I/O模型(nonblocking IO)
用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据
到达后，才真正读取到数据，继续执行。即 "轮询"机制存在两个问题：如果有大量文件描述符都要等，
那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户
态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长，
程序响应延迟就过大;设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式，一
般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。
非阻塞：程序向内核发送请I/O求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结
果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核I/O是否完
成。
查看上图可知，在设置连接为非阻塞时，当应用进程系统调用 recvfrom 没有数据返回时，内核会立即返
回一个 EWOULDBLOCK 错误，而不会一直阻塞到数据准备好。如上图在第四次调用时有一个数据报准
备好了，所以这时数据会被复制到 应用进程缓冲区 ，于是 recvfrom 成功返回数据
当一个应用进程这样循环调用 recvfrom 时，称之为轮询 polling 。这么做往往会耗费大量CPU时间，实
际使用很少5.3信号驱动式I/O模型(signal-driven IO)
信号驱动I/O的意思就是进程现在不用傻等着，也不用去轮询。而是让内核在数据就绪时，发送信号通知
进程。
调用的步骤是，通过系统调用 sigaction ，并注册一个信号处理的回调函数，该调用会立即返回，然后主
程序可以继续向下执行，当有I/O操作准备就绪,即内核数据就绪时，内核会为该进程产生一个 SIGIO信
号，并回调注册的信号回调函数，这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进
程所需要的数据从内核空间拷贝到用户空间
此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处
理函数的通知。
在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续
运行并不阻塞
在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续
运行并不阻塞
当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。优
点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此
可以提高资源的利用率
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
异步阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程
请求后
进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程。5.4异步I/O模型(asynchronous IO)
异步I/O 与 信号驱动I/O最大区别在于，信号驱动是内核通知用户进程何时开始一个I/O操作，而异步I/O
是由内核通知用户进程I/O操作何时完成，两者有本质区别,相当于不用去饭店场吃饭，直接点个外卖，把
等待上菜的时间也给省了
相对于同步I/O，异步I/O不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备
好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直
接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。
信号驱动IO当内核通知触发信号处理程序时，信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到
用户空间缓冲区这个阶段，而异步IO直接是在第二个阶段完成后，内核直接通知用户线程可以进行后续
操作了
优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠
缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的
异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编
程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求
Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、
libuv。
异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的
IO如果不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的
结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现
较大的同时并实现较高的IO复用，因此异步非阻塞使用最多的一种通信方式。
5.5多路复用I/O型(I/O multiplexing)
上面的模型中,每一个文件描述符对应的IO是由一个线程监控和处理
多路复用IO指一个线程可以同时（实际是交替实现，即并发完成）监控和处理多个文件描述符对应各自
的IO，即复用同一个线程
一个线程之所以能实现同时处理多个IO,是因为这个线程调用了内核中的SELECT,POLL或EPOLL等系统调
用，从而实现多路复用IOI/O multiplexing 主要包括:select，poll，epoll三种系统调用，select/poll/epoll的好处就在于单个
process就可以同时处理多个网络连接的IO。
它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数
据到达了，就通知用户进程。
当用户进程调用了select，那么整个进程会被block，而同时，kernel会"监视"所有select负责的socket，
当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从
kernel拷贝到用户进程。
Apache prefork是此模式的select，worker是poll模式。
IO多路复用（IO Multiplexing) ：是一种机制，程序注册一组socket文件描述符给操作系统，表示"我要
监视这些fd是否有IO事件发生，有了就告诉程序处理"IO多路复用一般和NIO一起使用的。NIO和IO多路
复用是相对独立的。NIO仅仅是指IO API总是能立刻返回，不会被Blocking;而IO多路复用仅仅是操作系统
提供的一种便利的通知机制。操作系统并不会强制这俩必须得一起用，可以只用IO多路复用 + BIO，这时
还是当前线程被卡住。IO多路复用和NIO是要配合一起使用才有
实际意义
IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，就通知该进程多个连接共用一
个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而不是阻塞在真
正的IO操作上用户首先将需要进行IO操作添加到select中，同时等待select系统调用返回。当数据到达
时，IO被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行从流程上来看，使用
select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及调用select函数的
额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已
有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种，一次只
能监控一个IO虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select
函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然
后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率IO多路复用是最常使用的IO
模型，但是其异步程度还不够"彻底"，因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称
为异步阻塞IO模型，而非真正的异步IO
优缺点
优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述
符一个线程)，这样可以大大节省系统资源缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理
需要 2 次系统调用，占用时间会有增加
IO****多路复用适用如下场合：
当客户端处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用
当一个客户端同时处理多个套接字时，此情况可能的但很少出现
当一个服务器既要处理监听套接字，又要处理已连接套接字，一般也要用到I/O复用
当一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用
当一个服务器要处理多个服务或多个协议，一般要使用I/O复用
1.3.3五种IO****对比
这五种 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O
操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配
常用I/O模型比较6****零拷贝
6.1****零拷贝介绍
传统Linux中I/O的问题
传统的 Linux 系统的标准 I/O 接口（read、write）是基于数据拷贝的，也就是数据都是 copy_to_user
或者 copy_from_user，这样做的好处是，通过中间缓存的机制，减少磁盘 I/O 的操作，但是坏处也很明
显，大量数据的拷贝，用户态和内核态的频繁切换，会消耗大量的 CPU 资源，严重影响数据传输的性
能，统计表明，在Linux协议栈中，数据包在内核态和用户态之间的拷贝所用的时间甚至占到了数据包整
个处理流程时间的57.1%
什么是零拷贝
零拷贝就是上述问题的一个解决方案，通过尽量避免拷贝操作来缓解 CPU 的压力。零拷贝并没有真正做
到"0"拷贝，它更多是一种思想，很多的零拷贝技术都是基于这个思想去做的优化
零拷页相关技术
MMAP ( Memory Mapping )mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间
后，进程可以向访问普通内存一样对文件进行访问。
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘
地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。
实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到
对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对
这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。
内存映射减少数据在用户空间和内核空间之间的拷贝操作,适合大量数据传输上面左图为传统读写,右图为MMAP.两者相比mmap要比普通的read系统调用少了一次copy的过程。因为
read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核
复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。SENDFIL
1.1.1Nginx的源码编译
1.下载软件
[root@Nginx ~]# wget https://nginx.org/download/nginx-1.28.1.tar.gz2.解压
[root@Nginx ~]# tar zxf nginx-1.28.1.tar.gz
[root@Nginx ~]# cd nginx-1.28.1/
[root@Nginx nginx-1.28.1]# ls
auto CHANGES.ru conf contrib html man SECURITY.md
CHANGES CODE_OF_CONDUCT.md configure CONTRIBUTING.md LICENSE README.md src3.检测环境
#安装依赖性
[root@Nginx ~]# dnf install gcc openssl-devel.x86_64 pcre2-devel.x86_64 zlib-devel -y
[root@Nginx nginx-1.28.1]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module4编译
[root@Nginx nginx-1.28.1]# make
[root@Nginx nginx-1.28.1]# make install5.nginx启动
#设定环境变量
[root@Nginx sbin]# vim ~/.bash_profile
export PATH=$PATH:/usr/local/nginx/sbin
[root@Nginx sbin]# source ~/.bash_profile
[root@Nginx logs]# useradd -s /sbin/nologin -M nginx
[root@Nginx logs]# nginx
[root@Nginx logs]# ps aux | grep nginx
root 44012 0.0 0.1 14688 2356 ? Ss 17:01 0:00 nginx: master process nginx
nginx 44013 0.0 0.2 14888 3892 ? S 17:01 0:00 nginx: worker process
root 44015 0.0 0.1 6636 2176 pts/0 S+ 17:01 0:00 grep --color=auto nginx
#测试
[root@Nginx logs]# echo timinglee > /usr/local/nginx/html/index.html
[root@Nginx logs]# curl 172.25.254.100
timinglee
6.编写启动文件
[root@Nginx ~]# vim /lib/systemd/system/nginx.service
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target
[root@Nginx ~]# systemctl daemon-reload
#验证
[root@Nginx ~]# systemctl status nginx.service
○ nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; preset: disabled)
Active: inactive (dead)
[root@Nginx ~]# systemctl enable --now nginx
[root@Nginx ~]# ps aux | grep nginx
root 1839 0.0 0.1 14688 2356 ? Ss 09:53 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1840 0.0 0.2 14888 3828 ? S 09:53 0:00 nginx: worker process
[root@Nginx ~]# reboot
[root@Nginx ~]# systemctl status nginx.service
1.1.2Nginx的平滑升级及回滚
1.下载高版本的软件
[root@Nginx ~]# wget https://nginx.org/download/nginx-1.29.4.tar.gz2.对于新版本的软件进行源码编译并进行平滑升级
#编译nginx隐藏版本
[root@Nginx ~]# tar zxf nginx-1.29.4.tar.gz
[root@Nginx ~]# cd nginx-1.29.4/src/core/
[root@Nginx core]# vim nginx.h
#define nginx_version 1029004
#define NGINX_VERSION ""
#define NGINX_VER "TIMINGLEE/" NGINX_VERSION
#文件编辑完成后进行源码编译即可
[root@Nginx core]# cd ../../
[root@Nginx nginx-1.29.4]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module
[root@Nginx nginx-1.29.4]# make
[root@Nginx nginx-1.29.4]# cd objs/
[root@Nginx objs]# ls
autoconf.err nginx ngx_auto_config.h ngx_modules.c src
Makefile nginx.8 ngx_auto_headers.h ngx_modules.o
[root@Nginx objs]# cd /usr/local/nginx/sbin/
[root@Nginx sbin]# ls
nginx
[root@Nginx sbin]# \cp -f /root/nginx-1.29.4/objs/nginx /usr/local/nginx/sbin/nginx
[root@Nginx sbin]# ls /usr/local/nginx/logs/
access.log error.log nginx.pid
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2360 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1644 0.0 0.2 14888 3896 ? S 09:55 0:00 nginx: worker process
[root@Nginx sbin]# kill -USR2 1643 #nginx master进程id
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1644 0.0 0.2 14888 3896 ? S 09:55 0:00 nginx: worker process
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4921 0.0 0.2 14916 4156 ? S 10:24 0:00 nginx: worker process
root 4923 0.0 0.1 6636 2176 pts/0 S+ 10:25 0:00 grep --color=auto nginx
[root@Nginx sbin]# ls /usr/local/nginx/logs/
access.log error.log nginx.pid nginx.pid.oldbin
#测试效果
[root@Nginx sbin]# nginx -V
nginx version: TIMINGLEE/
built by gcc 11.5.0 20240719 (Red Hat 11.5.0-5) (GCC)
built with OpenSSL 3.2.2 4 Jun 2024
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module
#回收旧版本子进程
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1644 0.0 0.2 14888 3896 ? S 09:55 0:00 nginx: worker process
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4921 0.0 0.2 14916 4156 ? S 10:24 0:00 nginx: worker process
root 4929 0.0 0.1 6636 2176 pts/0 S+ 10:27 0:00 grep --color=auto nginx
[root@Nginx sbin]# kill -WINCH 1643
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4921 0.0 0.2 14916 4156 ? S 10:24 0:00 nginx: worker process
root 4932 0.0 0.1 6636 2176 pts/0 S+ 10:28 0:00 grep --color=auto nginx3.版本回退|版本回滚
[root@Nginx sbin]# cd /usr/local/nginx/sbin/
[root@Nginx sbin]# cp nginx nginx.new -p
[root@Nginx sbin]# \cp nginx.old nginx -pf
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4921 0.0 0.2 14916 4156 ? S 10:24 0:00 nginx: worker process
[root@Nginx sbin]# kill -HUP 1643
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4921 0.0 0.2 14916 4156 ? S 10:24 0:00 nginx: worker process
nginx 4963 0.0 0.2 14888 3896 ? S 10:32 0:00 nginx: worker process
root 4965 0.0 0.1 6636 2176 pts/0 S+ 10:32 0:00 grep --color=auto nginx
[root@Nginx sbin]# nginx -V
nginx version: nginx/1.28.1
built by gcc 11.5.0 20240719 (Red Hat 11.5.0-5) (GCC)
built with OpenSSL 3.2.2 4 Jun 2024
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module
#回收新版本进程
[root@Nginx sbin]# kill -WINCH 4919
[root@Nginx sbin]# ps aux | grep nginx
root 1643 0.0 0.1 14688 2744 ? Ss 09:55 0:00 nginx: master process /usr/local/nginx/sbin/nginx
root 4919 0.0 0.4 14716 7936 ? S 10:24 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 4963 0.0 0.2 14888 3896 ? S 10:32 0:00 nginx: worker process
root 4969 0.0 0.1 6636 2176 pts/0 S+ 10:34 0:00 grep --color=auto nginx1.1.3Nginx配置文件的管理及优化参数
[root@Nginx ~]# vim /usr/local/nginx/conf/nginx.conf
user nginx;
[root@Nginx ~]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@Nginx ~]# nginx -s reload
[root@Nginx ~]# ps aux | grep nginx
root 5506 0.0 0.2 14564 3912 ? Ss 14:40 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 5511 0.0 0.2 14996 4032 ? S 14:41 0:00 nginx: worker process
[root@Nginx ~]# vim /usr/local/nginx/conf/nginx.conf
worker_processes 2;
[root@Nginx ~]# nginx -s reload
[root@Nginx ~]# ps aux | grep nginx
root 5506 0.0 0.2 14796 4040 ? Ss 14:40 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 5516 0.0 0.2 15012 4048 ? S 14:42 0:00 nginx: worker process
nginx 5517 0.0 0.2 15012 4048 ? S 14:42 0:00 nginx: worker process
#在vmware中更改硬件cpu核心个数，然后重启
[root@Nginx ~]# vim /usr/local/nginx/conf/nginx.conf
worker_processes auto;
worker_cpu_affinity 0001 0010 0100 1000;
[root@Nginx ~]# ps aux | grep nginx
root 887 0.0 0.1 14564 2212 ? Ss 14:51 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 889 0.0 0.2 14964 3748 ? S 14:51 0:00 nginx: worker process
nginx 890 0.0 0.2 14964 3748 ? S 14:51 0:00 nginx: worker process
nginx 891 0.0 0.2 14964 3748 ? S 14:51 0:00 nginx: worker process
nginx 892 0.0 0.2 14964 3748 ? S 14:51 0:00 nginx: worker process
[root@Nginx ~]# ps axo pid,cmd,psr | grep nginx
887 nginx: master process /usr/ 3
1635 nginx: worker process 0
1636 nginx: worker process 1
1637 nginx: worker process 2
1638 nginx: worker process 3
[root@Nginx ~]# vim /usr/local/nginx/conf/nginx.conf
events {
worker_connections 10000;
use epoll;
accept_mutex on;
multi_accept on;
}
[root@Nginx ~]# nginx -s reload
#测试并发
[root@Nginx ~]# dnf install httpd-tools -y
[root@Nginx ~]# ab -n 100000 -c5000 http://172.25.254.100/index.html
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 172.25.254.100 (be patient)
socket: Too many open files (24) #并发数量过多导致访问失败
#处理本地文件系统的并发文件数量
[root@Nginx ~]# vim /etc/security/limits.conf
* - nofile 100000
* - noproc 100000
root - nofile 100000
[root@Nginx ~]# sudo -u nginx ulimit -n
100000
[root@Nginx ~]# ulimit -n 10000
100000
#测试
[root@Nginx ~]# ab -n 100000 -c10000 http://172.25.254.100/index.html
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 172.25.254.100 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests