识别和解决Nginx性能瓶颈：故障排除指南

Nginx性能问题通常以简单的方式表现出来：页面加载缓慢、API调用开始超时、CPU飙升，或者用户开始看到502和504错误。难点在于判断Nginx是否是瓶颈，或者它只是第一个发出抱怨的服务。

当我排查Nginx问题时，我尽量不从修改指令开始。我首先会问几个简单的问题。延迟是否对所有路由都增加了，还是只针对访问某个上游的路由？静态文件也变慢了吗？错误是在部署、流量高峰、证书更改还是日志更改后开始的？这些背景信息通常比从旧帖子中复制调优块更能节省时间。

理解Nginx性能指标

在深入故障排除之前，理解什么构成性能瓶颈以及哪些是关键指标至关重要。瓶颈发生在系统中的某个组件限制了整体容量或速度时。对于Nginx，这通常与其处理请求、管理连接或高效提供内容的能力有关。

需要监控的关键指标包括：

活跃连接数： Nginx当前正在处理的客户端连接数。
每秒请求数（RPS）： Nginx处理请求的速率。
请求延迟： Nginx响应客户端请求所需的时间。
CPU使用率： Nginx工作进程消耗的CPU资源百分比。
内存使用率： Nginx进程使用的RAM量。
网络I/O： Nginx服务器进出数据传输的速率。
磁盘I/O： 如果Nginx直接提供静态文件或进行大量日志记录，则相关。

Nginx内置诊断工具

Nginx提供了多种功能来帮助您监控其运行状态并收集性能数据。

使用`stub_status`模块

stub_status模块提供了关于Nginx当前状态的基本但至关重要的信息。它是快速了解服务器活动概况的绝佳起点。

启用`stub_status`

要启用stub_status，请将以下配置块添加到您的nginx.conf中（通常位于监控端点的server块内）：

server {
    listen 80;
    server_name monitoring.example.com;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1; # 仅允许从本地主机访问
        deny all;
    }
}

修改配置后，重新加载Nginx：

sudo nginx -t # 测试配置
sudo nginx -s reload # 重新加载Nginx

解读`stub_status`输出

访问状态页面（例如，http://localhost/nginx_status）将看到类似以下的输出：

Active connections: 291
server accepts handled requests
 1162447 1162447 4496426
Reading: 6 Writing: 17 Waiting: 268

以下是每个指标的含义：

Active connections：当前活跃的客户端连接数，包括Reading、Writing和Waiting连接。
accepts：Nginx已接受的连接总数。
handled：Nginx已处理的连接总数。理想情况下，accepts和handled应相等。如果handled显著较低，可能表示资源限制（例如，worker_connections限制）。
requests：Nginx已处理的客户端请求总数。
Reading：Nginx当前正在读取请求头的连接数。
Writing：Nginx当前正在将响应写回客户端的连接数。
Waiting：等待请求的空闲客户端连接数（例如，keep-alive连接）。此处数值高可能表示keep-alive使用效率高，但也意味着工作进程被占用等待，如果活跃连接数低且资源受限，这可能是一个问题。

利用Nginx Plus API获取高级指标

对于Nginx Plus用户，Nginx Plus API提供了一个更详细的实时JSON接口用于监控。该API提供了区域、服务器、上游、缓存等的细粒度指标，对于深入性能分析和集成监控仪表板非常宝贵。

启用Nginx Plus API

在您的Nginx Plus配置中为API配置一个位置：

http {
    server {
        listen 8080;

        location /api {
            api write=on;
            allow 127.0.0.1; # 为安全限制访问
            deny all;
        }

        location /api.html {
            root /usr/share/nginx/html;
        }
    }
}

重新加载Nginx并访问http://localhost:8080/api以查看JSON输出。该API提供了大量数据，包括详细的连接统计信息、请求处理时间、上游健康状态和缓存性能，允许比stub_status更精细的故障排除。

Nginx访问日志和错误日志

Nginx日志是性能故障排除的信息宝库。它们记录每个请求和遇到的任何错误。

配置详细日志记录

您可以自定义log_format以包含有用的性能指标，如请求处理时间（$request_time）和上游响应时间（$upstream_response_time）。

http {
    log_format perf_log '$remote_addr - $remote_user [$time_local] "$request" ' 
                        '$status $body_bytes_sent "$http_referer" ' 
                        '"$http_user_agent" "$http_x_forwarded_for" ' 
                        'request_time:$request_time upstream_response_time:$upstream_response_time ' 
                        'upstream_addr:$upstream_addr';

    access_log /var/log/nginx/access.log perf_log;
    error_log /var/log/nginx/error.log warn;

    # 记录慢于阈值的请求的示例
    # 这更高级，可能需要自定义模块或单独的工具来解析。
    # 通常更容易解析主access_log以查找慢请求。
}

识别慢请求和错误

慢请求：使用grep或awk等工具解析访问日志，查找超过特定$request_time或$upstream_response_time阈值的请求。这有助于识别有问题的应用程序或外部服务。
```
awk 'match($0, /request_time:([0-9.]+)/, m) && m[1] > 1.0 {print $0}' /var/log/nginx/access.log
```
这避免依赖固定的日志字段编号，因为一旦请求路径、用户代理或引用者包含空格，该编号就会失效。
错误：监控error.log以查找关键问题，如“upstream timed out”、“no live upstreams”或“too many open files”。这些错误直接指向后端问题或Nginx资源限制。

外部系统监控工具

Nginx性能通常与底层服务器的资源相关。系统级监控提供了关键背景信息。

CPU使用率（top、htop、mpstat）：Nginx工作进程的高CPU使用率可能表示复杂的配置（正则表达式、SSL握手）、低效的代码或仅仅是高负载。
```
top -c # 显示按CPU使用率排序的进程
```
内存使用率（free -h、htop）：过多的内存消耗可能指向大的缓冲区大小（proxy_buffers）、内存泄漏或异常高的活跃连接数。
```
free -h # 显示人类可读的内存使用情况
```
磁盘I/O（iostat、iotop）：如果Nginx大量提供静态内容或进行大量日志记录，则相关。高磁盘I/O可能意味着存储瓶颈或日志记录过多。
```
iostat -x 1 10 # 每秒显示扩展磁盘统计信息，共10次
```
网络I/O（netstat、ss、iftop）：监控网络流量是否存在饱和或过多重传，这可能表示网络瓶颈或Nginx与客户端/上游之间的问题。
```
netstat -antp | grep nginx # 显示Nginx连接
```

常见的Nginx性能瓶颈及解决方案

有了监控数据，让我们看看常见问题及其解决方法。

1. 高CPU使用率

症状： top显示Nginx工作进程消耗大量CPU，即使负载适中。

原因：

多核CPU的工作进程数太少： Nginx可能未利用所有可用核心。
复杂的if语句或正则表达式： 过于复杂的正则表达式或配置中的许多if语句可能消耗大量CPU。
低效的SSL/TLS配置： 使用需要更多CPU的弱密码，或未利用可用的硬件加速。
过多的日志记录： 向磁盘写入过多数据，尤其是使用复杂的log_format规则时。
TLS、压缩或请求处理开销： 昂贵的TLS握手、高压缩级别、繁重的重写规则或非常大的请求头可能会推高CPU。

解决方案：

优化worker_processes： 设置worker_processes auto;（推荐）或设置为CPU核心数。每个工作进程是单线程的，可以充分利用一个CPU核心。
```
worker_processes auto;
```
简化配置： 检查if语句和正则表达式。考虑使用map指令或try_files实现更简单的逻辑。
优化SSL/TLS： 使用现代TLS设置，并在适当时启用ssl_session_cache和ssl_session_timeout以减少重复的握手工作。
控制日志记录： 使用缓冲的访问日志，或者如果不需要每个请求的记录，则禁用嘈杂静态资源的访问日志。
调查后端： 如果Nginx在等待，则瓶颈在上游。优化后端应用程序。

2. 响应时间慢

症状： 日志中$request_time或$upstream_response_time高；页面加载缓慢。

原因：

上游（后端）服务器问题： 最常见的原因。应用服务器生成响应缓慢。
大文件传输未进行适当优化： 提供大静态文件时未使用sendfile或gzip。
网络延迟： 客户端和Nginx之间或Nginx和上游之间的网络缓慢。
缺乏缓存： 重复获取动态内容。

解决方案：

优化上游健康检查和超时： 配置proxy_read_timeout、proxy_connect_timeout和proxy_send_timeout。为上游服务器实现健康检查。
```
location / {
    proxy_pass http://backend_app;
    proxy_read_timeout 90s; # 根据需要调整
    proxy_connect_timeout 5s;
}
```

启用gzip压缩： 对于基于文本的内容，gzip显著减少传输大小。

gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

启用sendfile和tcp_nodelay： 用于高效的静态文件服务。
```
sendfile on;
tcp_nodelay on;
```

实现缓存： 对动态内容使用proxy_cache，或为静态资源设置expires头。

# 静态资源示例
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 30d;
    log_not_found off;
}

3. 连接错误/连接数达到上限

症状： 客户端收到连接失败、502或504响应，或间歇性超时。stub_status可能显示接受的连接数快速上升，错误日志可能提到worker_connections are not enough、too many open files或上游连接失败。

原因：

达到worker_connections限制： Nginx无法接受新连接。
打开文件过多（ulimit）： 操作系统的文件描述符限制被达到。
后端饱和： 上游服务器不堪重负，不接受连接。
DDoS或异常高的合法流量。

解决方案：

增加worker_connections： 在events块内将此指令设置为高值（例如，10240或更高）。这是每个工作进程的最大连接数。
```
events {
    worker_connections 10240;
}
```
调整文件描述符限制： 增加操作系统的打开文件限制。在nginx.conf中添加worker_rlimit_nofile 65535;（如果适用），并通过systemd设置服务限制，在大多数现代Linux发行版上使用LimitNOFILE=65535。
优化keepalive_timeout： 如果客户端未重用连接，长时间的keep-alive超时可能会不必要地占用工作进程。如果Waiting连接数高而requests低，请缩短它。
```
keepalive_timeout 15s; # 默认是75s
```
实现负载均衡和扩展： 将流量分布到多个后端服务器。考虑Nginx的负载均衡能力（轮询、最少连接、IP哈希）。
速率限制： 使用limit_req或limit_conn模块保护您的服务器免受来自单个客户端的过多请求或连接。

4. 高内存使用率

症状： Nginx工作进程消耗大量RAM；服务器可能过度交换。

原因：

大的缓冲区大小： proxy_buffers、client_body_buffer_size、fastcgi_buffers配置过高。
广泛的缓存： 大的proxy_cache_path大小。
许多活跃连接： 每个连接需要一些内存。

解决方案：

调整缓冲区大小： 仅当日志显示存在实际缓冲区问题时才增加缓冲区大小，例如响应头对于配置的代理或FastCGI缓冲区过大。413 Request Entity Too Large由请求体限制（如client_max_body_size）控制，而非代理响应缓冲区。
```
proxy_buffer_size 4k;
proxy_buffers 8 8k;
```
优化缓存： 管理缓存大小和驱逐策略（proxy_cache_path参数）。
检查keepalive_timeout： 如前所述，过长的keepalive_timeout可能会使工作进程及其关联的内存保持活跃以处理空闲连接。

Nginx性能配置最佳实践

除了解决特定问题外，以下通用最佳实践有助于保持最佳的Nginx性能：

worker_processes auto;：利用所有CPU核心。
worker_connections：设置一个与预期并发和文件描述符限制匹配的值。对于繁忙的服务器，4096或8192是常见的起点，但正确的值取决于工作负载。
sendfile on;：用于高效的静态文件服务。
tcp_nodelay on;：确保小数据包立即传输，改善交互式服务的延迟。
keepalive_timeout：根据客户端行为调整；15-30秒通常是良好的平衡。
gzip on;：为基于文本的内容启用压缩。
proxy_buffering on;：通常保持缓冲开启。它允许Nginx将上游服务器的响应暂存到磁盘（如果需要），并尽可能快地发送给客户端，从而释放上游。仅当实时低延迟流式传输绝对关键且您理解其影响时才禁用。
expires头：在客户端积极缓存静态内容。
最小化if语句和正则表达式：选择map指令或try_files以获得更好的性能。
对静态文件使用access_log off;：如果日志记录不是严格必要的，减少频繁访问的静态资源的磁盘I/O。
HTTP/2：为现代浏览器启用HTTP/2，以改善HTTPS上的多路复用和头部压缩。
```
listen 443 ssl http2;
```

故障排除工作流程和策略

面对性能问题时，遵循结构化方法：

定义基准：了解健康时期的正常操作指标（CPU、内存、连接、RPS、延迟）。
监控症状：识别具体症状（例如，高CPU、慢请求、连接错误），并使用工具（stub_status、日志、top）确认它们。
提出假设：根据症状，对根本原因提出假设（例如，“高CPU是由于低效的正则表达式”）。
测试和分析：实施更改（例如，简化正则表达式）并监控其对指标的影响。分析新的日志条目或stub_status输出。
迭代：如果问题持续存在，完善您的假设并重复该过程。
记录：记录所做的更改及其效果，以供将来参考。

最好的Nginx性能修复通常是平淡无奇的：证明延迟在哪里，更改一件事，然后观察相同的指标。如果$upstream_response_time高，在责怪Nginx之前先调优应用程序路径。如果静态文件慢而上游时间为空，检查磁盘、网络、压缩和静态文件设置。如果错误提到文件描述符或工作进程连接，将这两个限制作为一对修复。这种习惯使故障排除基于证据而非传说。

识别和解决Nginx性能瓶颈：故障排除指南

理解Nginx性能指标

Nginx内置诊断工具

使用stub_status模块

启用stub_status

解读stub_status输出

利用Nginx Plus API获取高级指标

启用Nginx Plus API

Nginx访问日志和错误日志

配置详细日志记录

识别慢请求和错误

外部系统监控工具

常见的Nginx性能瓶颈及解决方案

1. 高CPU使用率

2. 响应时间慢

3. 连接错误/连接数达到上限

4. 高内存使用率

Nginx性能配置最佳实践

故障排除工作流程和策略

使用`stub_status`模块

启用`stub_status`

解读`stub_status`输出