Nginx

一、几种 IO 模型的原理

I/O 在计算机中指 Input/Output, IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数),是衡量磁盘性能的主要指标之一。IOPS 是指单位时间内系统能处理的 I/O 请求数量,一般以每秒处理的 I/O 请求数量为单位,I/O 请求通常为读或写数据操作请求。

一次完整的 I/O 是用户空间的进程数据与内核空间的内核数据的报文的完整交换,但是由于内核空间与用户空间是严格隔离的,所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据,而是需要经历一次从内核空间中的内存数据 copy 到用户空间的进程内存当中,所以简单说 I/O 就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。

1. I/O 模型相关概念

同步/异步:关注的是消息通信机制,即调用者在等待一件事情的处理结果时,被调用者是否提供完成状态的通知。

  • 同步:synchronous,被调用者并不提供事件的处理结果相关的通知消息,需要调用者主动询问事情是否处理完成。
  • 异步:asynchronous,被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态
用户空间
程序进程
内核准备好数据后
是否提供通知机制
不提供:同步
提供:异步

阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态

  • 阻塞:blocking,指 IO 操作需要彻底完成后才能返回到用户空间,调用结果返回之前,调用者被挂起,干不了别的事情。
  • 非阻塞:nonblocking,指 IO 操作被调用后立即返回给用户一个状态值,而无需等待 IO 操作彻底完成,在最终的调用结果返回之前,调用者不会被挂起,可以去做别的事情。
Syntax error in textmermaid version 10.9.0

2. 网络 I/O 模型原理

阻塞型、非阻塞型、复用型、信号驱动型、异步

  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 是否完成,这种方式简单,但是比较慢,用的比较少。

  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 时间,实际使用很少。

  3. 多路复用 I/O 模型(I/O multiplexing)

    上面的模型中,每一个文件描述符对应的 IO 是由一个线程监控和处理多路复用 IO 指一个线程可以同时(实际是交替实现,即并发完成)监控和处理多个文件描述符对应各自的 IO,即复用同一个线程

    一个线程之所以能实现同时处理多个 IO,是因为这个线程调用了内核中的 SELECT,POLL 或 EPOLL 等系统调用,从而实现多路复用 IO

    I/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 复用
  4. 信号驱动式 I/O 模型 (signal-driven IO)

    信号驱动 I/O 的意思就是进程现在不用傻等着,也不用去轮询。而是让内核在数据就绪时,发送信号通知进程。调用的步骤是,通过系统调用 sigaction ,并注册一个信号处理的回调函数,该调用会立即返回,然后主程序可以继续向下执行,当有 I/O 操作准备就绪,即内核数据就绪时,内核会为该进程产生一个 SIGIO 信号,并回调注册的信号回调函数,这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行,只要等待来自信号处理函数的通知。

    在信号驱动式 I/O 模型中,应用程序使用套接口进行信号驱动 I/O,并安装一个信号处理函数,进程继续运行并不阻塞,当数据准备好时,进程会收到一个 SIGIO 信号,可以在信号处理函数中调用 I/O 操作函数处理数据。

    优点:线程并没有在等待数据时被阻塞,内核直接返回调用接收信号,不影响进程继续处理其他请求因此可以提高资源的利用率。

    缺点:信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

    异步阻塞:程序进程向内核发送 IO 调用后,不用等待内核响应,可以继续接受其他请求,内核收到进程请求后进行的 IO 如果不能立即返回,就由内核等待结果,直到 IO 完成后内核再通知进程。

  5. 异步 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 复用,因此异步非阻塞使用最多的一种通信方式。

3. 五种 IO 模型对比

这五种 I/O 模型中,越往后,阻塞越少,理论上效率也是最优前四种属于同步 I/O,因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程,只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。

二、配置虚拟主机,实现强制 https 跳转访问 www.x.com(x.com 为自己定义的域名)

访问 http://www.test.org 跳转至 https://www.test.org

1. 安装 nginx

yum 安装 yum install nginx -y

或者编译安装

2. 创建证书

#! /bin/bash
/etc/init.d/functions
# 创建目录
mkdir -p /etc/pki/nginx/certs
cd /etc/pki/nginx/certs
#自签名CA证书
openssl req -newkey rsa:4096 -nodes -sha256 -keyout ca.key -x509 -days 3650 -out ca.crt <<EOF
CN
Jiangsu
Nanjing
shi.Ltd
shi
ca.shi.org
EOF
# 自制key和csr文件
openssl req -newkey rsa:4096 -nodes -sha256 -keyout www.test.org.key -out www.test.org.csr <<EOF
CN
Jiangsu
Nanjing
test.org
test.org
www.test.org
719537389@qq.com
EOF
# 签发证书
openssl x509 -req -days 3650 -in www.test.org.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out www.test.org.crt
# 合并CA和服务器证书一个文件,注意服务器证书在前
cat www.test.org.crt ca.crt > www.test.org.pem
chown -R nginx:nginx *
exit 0

3. 实现 https

配置 nginx.conf

#在http块修改sever内容
http{
......
server {
listen 80;
listen 443 ssl;
server_name www.test.org;
ssl_certificate /etc/pki/nginx/certs/www.test.org.pem;
ssl_certificate_key /etc/pki/nginx/certs/www.test.org.key;
ssl_session_cache shared:sslcache:20m;
ssl_session_timeout 10m;
if ($scheme = http) {
rewrite ^(.*) https://server_name$1 redirect;
}
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}

修改首页
hostname -I >/usr/share/nginx/html/index.html

重启服务

systemctl restart nginx

4. 验证 http 强制跳转 https

访问 http://www.test.com 强制跳转至 https://www.test.com




三、配置 nginx 通过不同 path 反代至不同后端 apache 服务器(即访问 www.a.com/a/反代至 apache1,访问 www.a.com/b/反代至 apache2)

www.a.com/a/
www.a.com/b/
Client
Proxy
Nginx
10.0.0.7
Apache1
10.0.0.17
Apache2
10.0.0.27

1. Apache1 配置

#yum安装httpd
yum install httpd -y
#准备页面
echo "Apache1" > /var/www/html/a/index.html

2. Apache2 配置

#yum安装httpd
yum install httpd -y
#准备页面
echo "Apache2" > /var/www/html/index.html

3. Nginx 配置

#配置nginx.conf
server {
...
location ^~ /a/ {
index index.html;
proxy_pass http://10.0.0.17:80; #最后不加/相当于访问http://10.0.0.17/a/index.html
}
location ^~ /b/ {
index index.html;
proxy_pass http://10.0.0.27:80/; #最后加/相当于访问http://10.0.0.27/index.html,不建议使用该方式
}
}

跳转验证

  • 访问 www.test.com/a/时反向代理至 10.0.0.17/a/


  • 访问 www.test.com/b/时反向代理至 10.0.0.27/


四、总结出现 2xx、3xx、4xx、5xx 状态码的原因

1. http 请求处理流程

一个普通的 http 请求处理流程,如上图所示:
A -> client 端发起请求给 nginx
B -> nginx 处理后,将请求转发到 uwsgi,并等待结果
C -> uwsgi 处理完请求后,返回数据给 nginx
D -> nginx 将处理结果返回给客户端
每个阶段都会有一个预设的超时时间,由于网络、机器负载、代码异常等等各种原因,如果某个阶段没有在预期的时间内正常返回,就会导致这次请求异常,进而产生不同的状态码。

2. nginx 状态码

nginx 状态码被分为六大类:

  • 000 未知错误默认 000
  • 100-199 用于指定客户端应响应的某些动作。
  • 200-299 用于表示请求成功。
  • 300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
  • 400-499 用于指出客户端的错误。
  • 500-599 用于支持服务器错误。

000

发生错误时,nginx找不到对应的httpcode码,于是默认赋值000
Failed DNS resolution
Connection refused
Connection timed out
Server actually returns 000 for some reason

2xx

200(成功)服务器已成功处理了请求。通常,表示服务器提供了请求的网页。
201(已创建)请求成功并且服务器创建了新的资源。
202(已接受)服务器已接受请求,但尚未处理。
203(非授权信息)服务器已成功处理了请求,但返回的信息可能来自另一来源。
204(无内容)服务器成功处理了请求,但没有返回任何内容。
205(重置内容)服务器成功处理了请求,但没有返回任何内容。
206(部分内容)服务器成功处理了部分GET请求。

3xx

300(多种选择)针对请求,服务器可执行多种操作。服务器可根据请求者 (user agent)选择一项操作,或提供操作列表供请求者选择。
301(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对GET或HEAD请求的响应)时,会自动将请求者转到新位置。
302(临时移动)服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
303(查看其他位置)请求者应当对不同的位置使用单独的GET请求来检索响应时,服务器返回此代码。
304(未修改)自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。
305(使用代理)请求者只能使用代理访问请求的网页。如果服务器返回此响应,还表示请求者应使用代理。
307(临时重定向)服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。

4xx

400 (错误请求)服务器不理解请求的语法。
401 (未授权)请求要求身份验证。对于需要登录的网页,服务器可能返回此响应。
403 (禁止)服务器拒绝请求。
404 (未找到)服务器找不到请求的网页。
405 (方法禁用)禁用请求中指定的方法。
406 (不接受)无法使用请求的内容特性响应请求的网页。
407 (需要代理授权)此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。
408 (请求超时)服务器等候请求时发生超时。
409 (冲突)服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。
410 (已删除)如果请求的资源已永久删除,服务器就会返回此响应。
411 (需要有效长度)服务器不接受不含有效内容长度标头字段的请求。
412 (未满足前提条件)服务器未满足请求者在请求中设置的其中一个前提条件。
413 (请求实体过大)服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
414 (请求的 URI 过长)请求的URI(通常为网址)过长,服务器无法处理。
415 (不支持的媒体类型)请求的格式不受请求页面的支持。
416 (请求范围不符合要求)如果页面无法提供请求的范围,则服务器会返回此状态代码。
417 (未满足期望值)服务器未满足"期望"请求标头字段的要求。
499 客户端主动断开了连接。

400错误

request header or cookie too large

解决办法

#修改nginx.conf,添加下面内容(即增加缓冲区)
......
http
{
......
client_header_buffer_size 8k; #默认是4k(可以稍微改大,比如16K)
large_client_header_buffers 4 8k;
......
}

499错误

client发送请求后,如果在规定的时间内(假设超时时间为500ms)没有拿到nginx给的响应,则认为这次请求超时,会主动结束,这个时候nginx的access_log就会打印499状态码。
A+B+C+D > 500ms
其实这个时候,server端有可能还在处理请求,只不过client断掉了连接,因此处理结果也无法返回给客户端。
499如果比较多的话,可能会引起服务雪崩。
比如说,client一直在发起请求,客户端因为某些原因处理慢了,没有在规定时间内返回数据,client认为请求失败,中断这次请求,然后再重新发起请求。这样不断的重复,服务端的请求越来越多,机器负载变大,请求处理越来越慢,没有办法响应任何请求

解决方法

#添加配置
proxy_ignore_client_abort on;

5xx

500 (服务器内部错误)服务器遇到错误,无法完成请求。
501 (尚未实施)服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
502 (错误网关)服务器作为网关或代理,从上游服务器收到无效响应。
503 (服务不可用)服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。
504 (网关超时)服务器作为网关或代理,但是没有及时从上游服务器收到请求。
505 (HTTP 版本不受支持)服务器不支持请求中所用的 HTTP 协议版本。

500错误

服务器内部错误,也就是服务器遇到意外情况,而无法执行请求。

发生错误,一般的几种情况:

  • web脚本错误,如php语法错误,lua语法错误等。
  • 访问量大的时候,由于系统资源限制,而不能打开过多的文件句柄

分析错误原因

  • 查看nginx,php的错误日志
  • 如果是too many open files,修改nginx的worker_rlimit_nofile参数,使用ulimit查看系统打开文件限制,修改/etc/security/limits.conf
  • 如果脚本存在问题,则需要修复脚本错误,并优化代码
  • 各种优化都做好,还是出现too many open files,那就需要考虑做负载均衡,把流量分散到不同服务器上去

502 错误

502主要针对B 、C阶段。

表示在nginx设置的超时时间内,上游uwsgi没有给正确的响应(但是是有响应的,不然如果一直没响应,就会变成504超时了),因此nginx这边的状态码为502。

Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)没有执行完毕而导致PHP-CGI进程终止。Nginx 502错误的原因比较多,一般就是因为在代理模式下后端服务器出现问题引起的。这些错误一般都不是nginx本身的问题,一定要从后端找原因!比如:php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉,都会出现502错误。502错误最通常的出现情况就是后端主机宕机!

一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关,php-fpm.conf有两个至关重要的参数,一个是"max_children",另一个是"request_terminate_timeout" ,但是这个值不是通用的,而是需要自己计算的。

解决方法

#Nginx提示502和504错误的临时解决办法是:调整php-fpm.conf的相关设置:
<value name=”max_children”>32</value>
<value name=”request_terminate_timeout”>30s</value> #fast-cgi的执行脚本时间

Nginx 502错误情况

1))网站的访问量大,而php-cgi的进程数偏少。
针对这种情况的502错误,只需增加php-cgi的进程数。具体就是修改/usr/local/php/etc/php-fpm.conf 文件,将其中的max_children值适当增加。
这个数据要依据你的VPS或独立服务器的配置进行设置。一般一个php-cgi进程占20M内存,你可以自己计算下,适量增多。
/usr/local/php/sbin/php-fpm restart 然后重启一下.
2))CPU占用率、内存占用率非常高,遭到CC攻击.
解决方法请参考:Linux VPS简单解决CC攻击
3)CPU占用率不高,内存溢出。
检查一下网站程序有没有问题?一般小偷站点常常会出现内存溢出。
检查一下/var/log/目录下的日志,看看是不是有人爆破SSH和FTP端口?
SSH、FTP遭到穷举也会占用大量内存。是的话改掉SSH端口和FTP端口即可。

503错误

503是服务不可用的返回状态。
由于在nginx配置中,设置了limit_req的流量限制,导致许多请求返回503错误代码,在限流的条件下,为提高用户体验,希望返回正常Code 200,且返回操作频繁的信息

504 错误

504 主要是针对 B、C 阶段。

Nginx 504 Gateway Time-out 的含义是所请求的网关没有请求到,简单来说就是没有请求到可以执行的 PHP-CGI。Nginx 504 Gateway Time-out 则是与 nginx.conf 的设置有关。504 Gateway Time-out 问题常见于使用 nginx 作为 web server 的服务器的网站。

一般看来, 这种情况可能是由于 nginx 默认的 fastcgi 进程响应的缓冲区太小造成的, 这将导致 fastcgi 进程被挂起, 如果你的 fastcgi 服务对这个挂起处理的不好, 那么最后就极有可能导致 504 Gateway Time-out 现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百 K 默认的 fastcgi 进程响应的缓冲区是 8K, 我们可以设置大点在 nginx.conf 里, 加入

fastcgi_buffers 8 128k
这表示设置fastcgi缓冲区为8×128k,当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点, 例如设置成60秒:
send_timeout 60;
只是调整了上面这两个参数, 结果可能就是没有再显示那个超时!
解决办法:调整nginx.conf的相关设置:
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_buffer_size 256k;
fastcgi_buffers 16 256k;
fastcgi_busy_buffers_size 512k;
fastcgi_temp_file_write_size 512k;
posted @   areke  阅读(87)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器
点击右上角即可分享
微信分享提示