OpenEuler系统Nginx性能优化全攻略

OpenEuler 系统 Nginx 服务性能优化与监控超详细教程

本教程适配 OpenEuler 22.03 LTS/24.03 LTS 主流长期支持版本，默认用户已完成 Nginx 部署（DNF / 源码编译均可），全程聚焦生产级全链路性能优化 与企业级可观测监控告警体系，覆盖系统内核、Nginx 核心配置、场景化专项调优、全维度监控、压测验证、瓶颈排查全流程，优化后可显著提升 Nginx 并发承载能力、降低响应延迟、优化服务器资源利用率。

---

前置说明与环境校验

1. 关键路径约定

• DNF/YUM 安装的 Nginx：主配置文件路径 /etc/nginx/nginx.conf，站点配置目录 /etc/nginx/conf.d/，systemd 服务名默认nginx
• 源码编译安装的 Nginx：主配置文件以编译时--prefix指定路径为准（常见为/usr/local/nginx/conf/nginx.conf），下文统称nginx.conf，请自行替换对应路径
• 所有操作均需sudo管理员权限，或 root 用户执行

2. 前置环境校验（优化前必做）

# 1. 验证Nginx运行状态
sudo systemctl status nginx

# 2. 查看Nginx编译参数与已加载模块（确认优化/监控所需模块是否开启）
nginx -V
# 核心必备模块校验：
# - 性能优化必备：--with-file-aio、--with-http_gzip_static_module、--with-threads、--with-stream
# - 监控必备：--with-http_stub_status_module（基础监控）、可选--with-http_v2_module（HTTP/2性能优化）

# 3. 验证配置文件语法合法性（每次修改配置后必须执行）
sudo nginx -t
# 输出 test is successful 方可重载配置生效
sudo nginx -s reload

---

一、OpenEuler 系统级内核性能优化（高并发核心基础）

Nginx 性能瓶颈 80% 优先出现在操作系统层面，本章节针对 OpenEuler 5.10 + 企业级内核深度适配，解决高并发下的连接耗尽、IO 瓶颈、CPU 调度效率低等核心问题，所有优化均经过生产环境验证。

1. 文件描述符全链路极限优化（高并发必做）

Linux 中 TCP 连接、文件读写均占用文件描述符，系统默认限制仅 1024，万级并发下会直接触发Too many open files报错，需完成系统级 - 用户级 - 服务级三层配置，避免配置不生效的高频坑。

步骤 1：系统级全局限制配置

# 创建Nginx专属内核参数配置文件
sudo tee /etc/sysctl.d/99-nginx-optimize.conf > /dev/null <<EOF
# 系统级全局最大文件描述符数量
fs.file-max = 2097152
# 单个进程可分配的最大文件数上限
fs.nr_open = 2097152
EOF

# 立即生效
sudo sysctl -p /etc/sysctl.d/99-nginx-optimize.conf

步骤 2：用户级资源限制配置

# 追加到系统资源限制配置，覆盖nginx用户与root用户
sudo tee -a /etc/security/limits.conf > /dev/null <<EOF
# nginx进程文件句柄软硬限制
nginx soft nofile 1048576
nginx hard nofile 1048576
nginx soft nproc 1048576
nginx hard nproc 1048576
# root用户全局限制
root soft nofile 1048576
root hard nofile 1048576
root soft nproc 1048576
root hard nproc 1048576
EOF

# 确保PAM模块加载限制配置（远程SSH登录生效）
sudo sed -i 's/#session    required     pam_limits.so/session    required     pam_limits.so/g' /etc/pam.d/sshd

步骤 3：systemd 服务级限制（90% 不生效的核心坑）

OpenEuler 通过 systemd 管理的服务，会优先读取服务自身的资源限制，忽略 limits.conf 配置，必须单独配置：

# 创建Nginx服务专属覆盖配置
sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo tee /etc/systemd/system/nginx.service.d/override.conf > /dev/null <<EOF
[Service]
# 解除文件句柄与进程数限制
LimitNOFILE=1048576
LimitNPROC=1048576
# 解除核心转储与内存锁定限制
LimitCORE=infinity
LimitMEMLOCK=infinity
EOF

# 重载systemd配置并重启Nginx生效
sudo systemctl daemon-reload
sudo systemctl restart nginx

# 验证配置是否生效（输出LimitNOFILE=1048576即为成功）
systemctl show nginx | grep LimitNOFILE

2. TCP 网络栈内核专项优化（适配 OpenEuler 5.10 + 内核）

针对 Nginx 高并发场景，优化 TCP 三次握手、四次挥手、连接复用、缓冲区等核心参数，解决 TIME_WAIT 堆积、连接队列溢出、握手失败、传输延迟高等问题。

# 追加到99-nginx-optimize.conf内核配置文件
sudo tee -a /etc/sysctl.d/99-nginx-optimize.conf > /dev/null <<EOF
# ==================== TCP连接队列优化（高并发核心） ====================
# 全连接队列最大长度，对应Nginx的listen backlog参数，高并发必须调大
net.core.somaxconn = 65535
# 半连接队列最大长度，防御SYN洪水攻击同时支撑高并发握手
net.ipv4.tcp_max_syn_backlog = 65535
# 网络设备接收数据包的队列最大长度，万兆网卡/高并发场景必调
net.core.netdev_max_backlog = 65535

# ==================== TIME_WAIT连接优化（解决端口耗尽） ====================
# 允许将TIME_WAIT状态的socket重新用于新的TCP连接，核心优化
net.ipv4.tcp_tw_reuse = 1
# 系统同时保持TIME_WAIT socket的最大数量，超出直接销毁
net.ipv4.tcp_max_tw_buckets = 2000000
# TCP连接关闭时FIN_WAIT2状态超时时间，默认60s，缩短为15s
net.ipv4.tcp_fin_timeout = 15
# 禁用tcp_tw_recycle，NAT环境下会导致握手失败，绝对不要开启
net.ipv4.tcp_tw_recycle = 0

# ==================== TCP长连接保活优化 ====================
# TCP长连接保活探测起始时间，默认2小时，缩短为10分钟
net.ipv4.tcp_keepalive_time = 600
# 保活探测包发送间隔
net.ipv4.tcp_keepalive_intvl = 15
# 保活探测失败最大重试次数，超出判定连接断开
net.ipv4.tcp_keepalive_probes = 3

# ==================== TCP缓冲区与传输性能优化 ====================
# 系统套接字接收缓冲区最大值（128MB）
net.core.rmem_max = 134217728
# 系统套接字发送缓冲区最大值（128MB）
net.core.wmem_max = 134217728
# TCP接收缓冲区（最小、默认、最大值）
net.ipv4.tcp_rmem = 4096 87380 134217728
# TCP发送缓冲区（最小、默认、最大值）
net.ipv4.tcp_wmem = 4096 65536 134217728
# TCP全局内存管理，避免频繁内存申请释放
net.ipv4.tcp_mem = 131072 262144 524288
# 开启TCP窗口缩放，支持大带宽长距离传输
net.ipv4.tcp_window_scaling = 1
# 开启TCP选择性应答，提升丢包场景下的传输效率
net.ipv4.tcp_sack = 1

# ==================== 安全与性能兼顾的辅助优化 ====================
# 开启SYN Cookies，防御SYN洪水攻击，不影响正常并发
net.ipv4.tcp_syncookies = 1
# 禁用连接空闲后的TCP慢启动，大幅提升长连接传输效率
net.ipv4.tcp_slow_start_after_idle = 0
# 禁用IP源路由、重定向，防范IP欺骗与攻击
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
# 开启反向路径过滤，防范IP欺骗攻击
net.ipv4.conf.all.rp_filter = 1
EOF

# 立即生效所有内核参数
sudo sysctl -p /etc/sysctl.d/99-nginx-optimize.conf

3. CPU 调度与 NUMA 架构极致优化

OpenEuler 多用于企业级物理机 / 云服务器，多为 NUMA 架构，跨 NUMA 节点调度会导致 CPU 缓存失效、性能下降，需针对性优化。

# 1. 查看服务器NUMA节点分布（确认节点数量与对应CPU核心）
numactl -H

# 2. 核心优化1：禁用irqbalance服务，手动绑定网卡中断到指定NUMA节点CPU
# 高并发万兆网卡场景必做，避免中断不均衡导致的CPU单核瓶颈
sudo systemctl stop irqbalance
sudo systemctl disable irqbalance

# 3. 核心优化2：OpenEuler内核CPU调度参数优化
sudo tee -a /etc/sysctl.d/99-nginx-optimize.conf > /dev/null <<EOF
# 减少进程频繁上下文切换，提升CPU缓存命中率
kernel.sched_migration_cost_ns = 5000000
# 提升唤醒进程的优先级，降低Nginx请求处理延迟
kernel.sched_autogroup_enabled = 0
EOF
sudo sysctl -p /etc/sysctl.d/99-nginx-optimize.conf

4. 内存与磁盘 IO 性能优化

# 1. 内存调度优化
sudo tee -a /etc/sysctl.d/99-nginx-optimize.conf > /dev/null <<EOF
# 降低swap使用率，优先使用物理内存，Nginx场景严禁依赖swap
vm.swappiness = 10
# 提升系统脏页刷新阈值，避免频繁IO写入，静态资源服务场景适配
vm.dirty_background_ratio = 10
vm.dirty_ratio = 30
EOF
sudo sysctl -p /etc/sysctl.d/99-nginx-optimize.conf

# 2. 透明大页（THP）优化：Nginx高并发场景禁用THP，减少内存碎片与延迟
sudo tee /etc/systemd/system/disable-thp.service > /dev/null <<EOF
[Unit]
Description=Disable Transparent Huge Pages (THP)
After=sysinit.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start disable-thp
sudo systemctl enable disable-thp

# 3. IO调度器优化：SSD硬盘使用mq-deadline，机械硬盘使用bfq
# 查看当前磁盘调度器
cat /sys/block/sda/queue/scheduler
# 永久修改（替换sda为你的业务磁盘名）
sudo tee /etc/udev/rules.d/60-io-scheduler.rules > /dev/null <<EOF
ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"
EOF
sudo udevadm control --reload-rules
sudo udevadm trigger

---

二、Nginx 核心配置全维度性能优化

本章节覆盖 Nginx 从全局到场景化的全配置优化，所有参数均标注作用、最佳实践值与适用场景，避免盲目复制配置。

1. 全局块（main）核心优化（全局生效）

位于nginx.conf最顶端，是 Nginx 的顶层配置，直接决定进程级性能表现。

# 1. 工作进程数：最佳实践为等于CPU核心数，auto自动适配
worker_processes auto;

# 2. CPU亲和性绑定：将每个worker进程绑定到固定CPU核心，避免进程切换导致的缓存失效
# 8核CPU手动绑定示例：worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
# 新版本Nginx推荐auto自动绑定，适配NUMA架构
worker_cpu_affinity auto;

# 3. 单个worker进程最大文件句柄数：必须小于等于系统级LimitNOFILE
worker_rlimit_nofile 1048576;

# 4. 进程优先级：调整为-10（优先级高于普通用户进程，范围-20~19，数值越小优先级越高）
worker_priority -10;

# 5. 定时器精度：高并发场景设置为100ms，减少频繁系统调用，降低CPU占用
timer_resolution 100ms;

# 6. 核心文件生成配置，用于故障排查
worker_rlimit_core 500M;
working_directory /tmp;

2. events 事件模块优化（高并发连接处理核心）

决定 Nginx 的连接处理模型与并发承载能力，是高并发场景的核心优化点。

events {
    # 1. 强制使用epoll事件模型，OpenEuler内核原生支持，是Linux下最高效的IO多路复用模型
    use epoll;

    # 2. 单个worker进程最大并发连接数：上限=worker_rlimit_nofile，理论总并发=worker_processes * worker_connections
    # 注意：反向代理场景下，一个请求会占用2个连接（客户端+上游），需预留余量
    worker_connections 524288;

    # 3. 批量接受新连接：开启后，worker进程一次性接受全连接队列的所有连接，大幅提升高并发处理效率
    multi_accept on;

    # 4. 关闭accept_mutex锁：高并发场景关闭，避免worker进程争抢锁导致的性能损耗
    # 低并发场景开启，实现负载均衡；万级以上并发必须关闭
    accept_mutex off;

    # 5. 延迟接受连接：只有当客户端请求数据到达后，才唤醒worker进程处理，减少空进程唤醒，降低CPU占用
    accept_mutex_delay 500ms;
}

3. http 核心块通用性能优化（所有站点全局生效）

覆盖 HTTP 协议层面的通用优化，对所有 server 站点生效，兼顾性能与兼容性。

http {
    # ==================== 基础传输性能优化 ====================
    # 1. 开启高效文件传输模式，内核直接将文件从磁盘缓存发送到网卡，跳过用户态拷贝，静态资源场景必开
    sendfile on;

    # 2. 开启TCP_NOPUSH：配合sendfile使用，将数据包攒到最大后一次性发送，减少小包数量，降低网络IO开销
    tcp_nopush on;

    # 3. 开启TCP_NODELAY：禁用Nagle算法，针对小包实时传输场景（反向代理/API接口），降低延迟
    # 注意：静态资源场景配合tcp_nopush使用，互不冲突
    tcp_nodelay on;

    # 4. 开启异步文件IO，配合sendfile使用，大幅提升大文件静态资源读写性能
    aio on;
    # 大于4MB的文件直接使用directio，跳过系统页缓存，避免内存占用过高
    directio 4m;
    directio_alignment 512;

    # ==================== 长连接性能优化 ====================
    # 1. 客户端与Nginx长连接超时时间，单位秒，高频访问场景设置30-60s，减少频繁TCP握手
    keepalive_timeout 60s;
    # 2. 单个长连接最多处理的请求数，高并发场景调大，避免频繁断开重连
    keepalive_requests 10000;
    # 3. 长连接发送响应后，等待客户端新请求的超时时间
    keepalive_time 1h;

    # ==================== 压缩传输优化 ====================
    # 1. 开启gzip压缩，减少传输带宽占用，提升页面加载速度
    gzip on;
    # 2. 不压缩小于1KB的文件，避免压缩开销大于收益
    gzip_min_length 1k;
    # 3. 压缩级别：1-9，级别越高压缩率越高，CPU占用越高，最佳实践为4-6
    gzip_comp_level 5;
    # 4. 需要压缩的文件类型
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # 5. 开启静态预压缩，直接读取同名.gz文件，避免重复压缩消耗CPU
    gzip_static on;
    # 6. 禁用IE6及以下版本的gzip，兼容老旧浏览器
    gzip_disable "MSIE [1-6]\.";
    # 7. 压缩后添加Vary头，避免CDN缓存兼容问题
    gzip_vary on;

    # ==================== 缓存与超时优化 ====================
    # 1. 客户端请求头读取超时时间，防范慢速攻击
    client_header_timeout 10s;
    # 2. 客户端请求体读取超时时间
    client_body_timeout 10s;
    # 3. 响应数据发送超时时间
    send_timeout 30s;
    # 4. 客户端最大请求体大小，根据业务调整（文件上传场景需调大）
    client_max_body_size 100m;

    # 5. 隐藏Nginx版本号，提升安全性，减少恶意扫描
    server_tokens off;

    # 6. 开启高效的哈希表，提升配置解析与请求匹配速度
    server_names_hash_bucket_size 128;
    server_names_hash_max_size 4096;
    types_hash_max_size 4096;
    types_hash_bucket_size 128;

    # ==================== 日志性能优化 ====================
    # 1. 自定义访问日志格式，添加性能监控核心字段（响应时间、上游耗时等）
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" '
                    '$request_time $upstream_response_time $upstream_connect_time';
    
    # 2. 访问日志缓冲优化：开启缓冲，减少磁盘IO频繁写入，高并发场景必开
    access_log /var/log/nginx/access.log main buffer=64k flush=5s;
    # 3. 错误日志级别调整，生产环境设置为warn，减少日志写入量
    error_log /var/log/nginx/error.log warn;

    # 引入站点配置文件
    include /etc/nginx/conf.d/*.conf;
}

4. 场景化专项性能优化

针对不同业务场景，提供精准的专项优化配置，避免通用配置的局限性。

场景 1：静态资源服务专项优化（图片 / JS/CSS/ 文件下载）

server {
    listen 80 backlog=65535;
    server_name static.example.com;
    root /data/static;

    # 核心优化1：开启文件缓存，将静态文件元信息缓存到内存，减少磁盘IO
    open_file_cache max=100000 inactive=60s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # 核心优化2：浏览器强缓存，静态资源长期缓存，减少重复请求
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header ETag "$sent_http_etag";
        # 关闭不必要的日志，减少IO
        access_log off;
    }

    # 核心优化3：大文件下载优化
    location ~* \.(zip|rar|tar|gz|iso|mp4|avi)$ {
        aio on;
        directio 8m;
        # 限速配置，按需开启
        # limit_rate 2m;
        # limit_rate_after 10m;
        expires 7d;
        access_log off;
    }

    # 核心优化4：首页/HTML文件缓存优化
    location ~* \.(html|htm)$ {
        expires 5m;
        add_header Cache-Control "public, max-age=300";
    }
}

场景 2：反向代理 / 负载均衡专项优化

# 上游服务配置
upstream backend {
    # 负载均衡策略，默认轮询，可选ip_hash/least_conn/least_time
    least_conn;
    # 核心优化1：开启上游服务长连接复用，避免每次请求重新建立TCP连接
    keepalive 32;
    # 单个长连接最大请求数
    keepalive_requests 10000;
    # 长连接空闲超时时间
    keepalive_timeout 60s;

    server 192.168.1.10:8080 max_fails=3 fail_timeout=10s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=10s;
}

server {
    listen 80 backlog=65535;
    server_name api.example.com;

    # 核心优化2：代理缓冲配置，开启后Nginx异步接收上游响应，再发给客户端，降低上游阻塞
    proxy_buffering on;
    proxy_buffer_size 64k;
    proxy_buffers 8 64k;
    proxy_busy_buffers_size 128k;
    proxy_temp_file_write_size 128k;
    # 禁用临时文件，避免磁盘IO，内存充足场景必开
    proxy_max_temp_file_size 0;

    # 核心优化3：代理超时配置，避免无效长连接占用资源
    proxy_connect_timeout 5s;
    proxy_send_timeout 10s;
    proxy_read_timeout 30s;
    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_next_upstream_tries 2;

    # 核心优化4：请求头优化，传递真实客户端IP
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    # 核心：开启HTTP/1.1长连接，关闭Connection头，实现上游连接复用
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    # 反向代理转发
    location / {
        proxy_pass http://backend;
    }
}

场景 3：HTTPS/TLS 性能专项优化

server {
    listen 443 ssl http2 backlog=65535;
    server_name example.com;

    # 证书配置
    ssl_certificate /etc/nginx/cert/example.com.crt;
    ssl_certificate_key /etc/nginx/cert/example.com.key;

    # 核心优化1：TLS协议版本优化，禁用老旧不安全协议，优先TLS 1.3
    ssl_protocols TLSv1.2 TLSv1.3;
    # 核心优化2：加密套件优化，优先选择ECDH系列，兼顾安全与性能
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;

    # 核心优化3：SSL会话复用，减少HTTPS握手次数，大幅降低握手延迟与CPU占用
    ssl_session_cache shared:SSL:100m; # 100M缓存可存储约40万个会话
    ssl_session_timeout 1d;
    ssl_session_tickets on;
    ssl_session_ticket_key /etc/nginx/cert/ticket.key;

    # 核心优化4：OCSP装订，客户端无需查询CA服务器，提升握手速度与隐私性
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/cert/ca-bundle.crt;
    resolver 223.5.5.5 114.114.114.114 valid=300s;
    resolver_timeout 5s;

    # 核心优化5：HSTS强制HTTPS，减少HTTP跳转请求
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # 业务配置
    root /data/www;
    index index.html;
}

---

三、Nginx 全维度监控体系搭建

从开箱即用的内置监控，到生产级 Prometheus+Grafana 全链路监控，覆盖指标、日志、链路全维度可观测能力，适配 OpenEuler 系统。

1. Nginx 内置基础监控（零依赖，开箱即用）

基于 Nginx 原生ngx_http_stub_status_module模块，无需额外部署任何组件，快速实现核心指标监控。

步骤 1：配置状态监控端点

# 新增专属监控站点配置，或添加到现有server中
server {
    listen 8080;
    server_name localhost;
    # 安全限制：仅允许本地与内网IP访问，禁止公网暴露
    allow 127.0.0.1;
    allow 192.168.0.0/16;
    allow 10.0.0.0/8;
    deny all;

    # 监控端点
    location /nginx_status {
        stub_status;
        # 关闭监控端点的日志，减少IO
        access_log off;
    }
}

步骤 2：重载配置并验证

sudo nginx -t && sudo nginx -s reload
# 访问测试，返回监控指标即为成功
curl http://127.0.0.1:8080/nginx_status

步骤 3：核心指标详细解读

Active connections: 289  # 当前活跃的客户端连接数（包括Waiting空闲连接）
server accepts handled requests
 1928304  1928304  9862157
# 1. accepts：Nginx启动以来总共接受的TCP连接数
# 2. handled：成功处理的连接数，正常情况下与accepts相等，差值为连接丢弃数
# 3. requests：总共处理的客户端请求数，长连接场景下，一个连接对应多个请求
Reading: 5  Writing: 36  Waiting: 248
# 1. Reading：正在读取客户端请求头的连接数，数值过高可能存在慢速攻击/请求体过大
# 2. Writing：正在向客户端发送响应数据的连接数，数值过高可能响应体过大/客户端网络慢
# 3. Waiting：空闲等待新请求的长连接数，数值高说明长连接复用效果好，无性能问题

步骤 4：基础监控脚本（定时采集 + 告警）

# 创建监控脚本
sudo tee /usr/local/bin/nginx_monitor.sh > /dev/null <<'EOF'
#!/bin/bash
# Nginx基础监控脚本，适配OpenEuler
STATUS_URL="http://127.0.0.1:8080/nginx_status"
LOG_FILE="/var/log/nginx/monitor.log"
ALERT_THRESHOLD_ACTIVE=5000  # 活跃连接数告警阈值
ALERT_THRESHOLD_5XX=100       # 5xx错误数告警阈值

# 1. 检查Nginx服务是否存活
if ! systemctl is-active --quiet nginx; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') CRITICAL: Nginx服务已宕机" >> $LOG_FILE
    # 可添加邮件/企业微信/钉钉告警逻辑
    exit 1
fi

# 2. 获取状态指标
STATUS_DATA=$(curl -s $STATUS_URL)
if [ $? -ne 0 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') CRITICAL: 无法获取Nginx状态指标" >> $LOG_FILE
    exit 1
fi

# 3. 解析指标
ACTIVE_CONN=$(echo "$STATUS_DATA" | grep 'Active connections' | awk '{print $3}')
ACCEPTS=$(echo "$STATUS_DATA" | awk NR==3 | awk '{print $1}')
HANDLED=$(echo "$STATUS_DATA" | awk NR==3 | awk '{print $2}')
REQUESTS=$(echo "$STATUS_DATA" | awk NR==3 | awk '{print $3}')
READING=$(echo "$STATUS_DATA" | grep 'Reading' | awk '{print $2}')
WRITING=$(echo "$STATUS_DATA" | grep 'Writing' | awk '{print $4}')
WAITING=$(echo "$STATUS_DATA" | grep 'Waiting' | awk '{print $6}')

# 4. 5xx错误数统计
ERROR_5XX=$(tail -1000 /var/log/nginx/access.log | grep ' 50[0-9] ' | wc -l)

# 5. 写入日志
echo "$(date '+%Y-%m-%d %H:%M:%S') INFO: Active=$ACTIVE_CONN Reading=$READING Writing=$WRITING Waiting=$WAITING Requests=$REQUESTS 5XX=$ERROR_5XX" >> $LOG_FILE

# 6. 阈值告警
if [ $ACTIVE_CONN -ge $ALERT_THRESHOLD_ACTIVE ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') ALERT: 活跃连接数超过阈值，当前$ACTIVE_CONN" >> $LOG_FILE
fi
if [ $ERROR_5XX -ge $ALERT_THRESHOLD_5XX ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') ALERT: 5xx错误数超过阈值，当前$ERROR_5XX" >> $LOG_FILE
fi
EOF

# 赋予执行权限
sudo chmod +x /usr/local/bin/nginx_monitor.sh
# 配置定时任务，每分钟执行一次
echo "* * * * * root /usr/local/bin/nginx_monitor.sh" | sudo tee -a /etc/crontab
sudo systemctl restart crond

2. OpenEuler 原生工具实时监控（快速定位瓶颈）

无需额外部署组件，利用系统原生工具，快速排查 Nginx 的 CPU、内存、网络、IO 瓶颈。

表格

工具	核心用途	Nginx 场景专用命令
top/htop	进程 CPU / 内存占用监控	top -p $(pidof nginx) 实时查看 Nginx worker 进程资源占用，定位 CPU / 内存瓶颈
ss	网络连接状态监控	`ss -ant	grep :80	awk '{++s [$1]} END {for (k in s) print k,s [k]}'` 统计 80 端口 TCP 连接状态分布，排查 TIME_WAIT/ESTABLISHED 堆积
netstat	连接队列监控	`netstat -s	grep 'listen queue'` 查看全连接队列溢出情况，排查握手失败问题
lsof	进程文件句柄占用	`lsof -p $(pidof nginx	awk '{print $1}')	wc -l` 统计 Nginx 进程占用的文件句柄数，排查句柄泄露
vmstat	系统 CPU / 内存 / IO 全局监控	vmstat 1 10 每秒采样一次，共 10 次，查看上下文切换 cs、CPU 空闲 id、等待 IO wa，定位系统级瓶颈
iostat	磁盘 IO 性能监控	iostat -x 1 10 查看磁盘 % util 使用率、await 响应时间，排查 IO 瓶颈导致的响应缓慢
iftop	网络带宽占用监控	iftop -i eth0 查看网卡实时带宽占用，定位流量占满导致的性能瓶颈
awk/grep	日志实时分析	`tail -f /var/log/nginx/access.log	awk 'request_time \> 1 {print 0}'` 实时查看响应时间超过 1s 的慢请求

3. 企业级 Prometheus + Grafana 监控体系（生产环境标准方案）

实现 Nginx 指标的可视化、趋势分析、智能告警，是企业级生产环境的标准监控方案，完美适配 OpenEuler 系统。

方案选型

推荐使用nginx-prometheus-exporter，官方维护，兼容性强，无需重新编译 Nginx，适配所有已安装的 Nginx 版本。

步骤 1：OpenEuler 上部署 nginx-prometheus-exporter

# 1. 下载最新稳定版exporter（AMD64架构，ARM架构请替换对应安装包）
wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v1.3.0/nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
sudo tar -zxvf nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz -C /usr/local/bin/
sudo chmod +x /usr/local/bin/nginx-prometheus-exporter

# 2. 配置systemd服务管理
sudo tee /usr/lib/systemd/system/nginx-exporter.service > /dev/null <<EOF
[Unit]
Description=Nginx Prometheus Exporter
After=network.target nginx.service

[Service]
Type=simple
User=nginx
ExecStart=/usr/local/bin/nginx-prometheus-exporter \
  --nginx.scrape-uri=http://127.0.0.1:8080/nginx_status \
  --web.listen-address=:9113
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target
EOF

# 3. 启动服务并设置开机自启
sudo systemctl daemon-reload
sudo systemctl start nginx-exporter
sudo systemctl enable nginx-exporter

# 4. 验证指标采集
curl http://127.0.0.1:9113/metrics
# 输出nginx开头的指标即为成功

步骤 2：Prometheus 配置采集

在 Prometheus 配置文件中添加 Nginx 采集任务：

scrape_configs:
  - job_name: "nginx"
    scrape_interval: 15s
    static_configs:
      - targets: ["你的Nginx服务器IP:9113"]
        labels:
          instance: nginx-prod-01

重载 Prometheus 配置，即可完成指标采集。

步骤 3：Grafana 可视化仪表盘

1. 登录 Grafana，进入「Connections」-「Data sources」，添加 Prometheus 数据源
2. 进入「Dashboards」-「Import」，输入仪表盘 ID 12708（Nginx 官方推荐仪表盘，覆盖所有核心指标），选择 Prometheus 数据源，点击导入
3. 核心监控大盘包含：
   • 全局指标：QPS、并发连接数、请求成功率、平均响应时间
   • 连接指标：连接状态分布、握手成功率、长连接复用率
   • 流量指标：入站 / 出站带宽、请求体 / 响应体大小分布
   • 错误指标：4xx/5xx 错误率、TOP 错误接口、错误趋势
   • 性能指标：P95/P99 响应延迟、读写等待耗时、上游服务响应时间

步骤 4：核心告警规则配置

在 Prometheus 中配置核心告警规则，实现故障提前预警：

groups:
- name: nginx-alert
  rules:
  # 告警1：Nginx服务宕机
  - alert: NginxDown
    expr: nginx_up == 0
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "Nginx服务已宕机"
      description: "实例{{ $labels.instance }}的Nginx服务无法访问，已持续30秒"

  # 告警2：5xx错误率超过1%
  - alert: Nginx5xxErrorRate
    expr: sum(rate(nginx_http_responses_total{code=~"5.."}[5m])) / sum(rate(nginx_http_responses_total[5m])) * 100 > 1
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "Nginx 5xx错误率超标"
      description: "实例{{ $labels.instance }}的5xx错误率当前为{{ $value | humanize }}%，超过阈值1%"

  # 告警3：活跃连接数超过阈值
  - alert: NginxHighActiveConnections
    expr: nginx_connections_active > 10000
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Nginx活跃连接数过高"
      description: "实例{{ $labels.instance }}的活跃连接数当前为{{ $value }}，超过阈值10000"

  # 告警4：响应延迟超标
  - alert: NginxHighLatency
    expr: nginx_http_request_duration_seconds{quantile="0.99"} > 0.5
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Nginx P99响应延迟超标"
      description: "实例{{ $labels.instance }}的P99响应延迟当前为{{ $value }}s，超过阈值500ms"

4. 日志深度监控与性能瓶颈定位

（1）慢请求日志配置与分析

通过自定义日志格式，精准定位慢请求、上游服务瓶颈，是性能优化的核心依据。

# 在http块中添加慢请求日志配置
log_format slow_log '$remote_addr [$time_local] "$request" '
                    '$status $request_time $upstream_response_time '
                    '"$http_referer" "$http_user_agent"';

# 在server块中开启慢请求日志，仅记录响应时间超过1s的请求
map $request_time $slow_request {
    default 0;
    ~^[1-9]\d*(\.\d+)?$ 1;
}
access_log /var/log/nginx/slow.log slow_log if=$slow_request;

（2）常用日志分析命令

# 1. 统计TOP10慢请求接口
awk '{print $7,$4}' /var/log/nginx/slow.log | sort -k2 -rn | head -10

# 2. 统计请求状态码分布
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# 3. 统计TOP10访问IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 4. 统计平均响应时间与P99响应时间
awk '{sum+=$11} END {print "平均响应时间：", sum/NR, "s"}' /var/log/nginx/access.log
awk '{print $11}' /var/log/nginx/access.log | sort -n | awk 'BEGIN{count=0} {arr[count++]=$1} END{print "P99响应时间：", arr[int(count*0.99)], "s"}'

---

四、优化效果压测验证与调优闭环

优化完成后，必须通过标准化压测验证效果，建立基准线，形成「压测 - 发现瓶颈 - 优化 - 验证」的调优闭环。

1. 压测工具部署（OpenEuler 适配）

推荐使用wrk，轻量高效，支持高并发压测，精准统计延迟分布，适配 OpenEuler 系统：

# OpenEuler官方源直接安装
sudo dnf install -y wrk

# 可选辅助工具：ab、hey
sudo dnf install -y httpd-tools

2. 压测前准备

1. 环境规范：压测机与 Nginx 服务器需在同一内网，避免公网带宽成为瓶颈；禁止在 Nginx 服务器上运行压测工具，占用服务器资源导致结果失真。
2. 基准线建立：优化前执行一次标准压测，记录核心指标（QPS、平均延迟、P99 延迟、错误率、CPU / 内存利用率），作为优化对比基准。
3. 压测场景匹配：压测文件 / 接口必须与实际业务一致，静态资源场景压测真实图片 / JS 文件，API 场景压测真实业务接口，避免压测默认 index.html 导致结果失真。

3. 标准压测命令与指标解读

# 标准压测命令：8线程，1000并发，持续30秒，压测目标地址
wrk -t8 -c1000 -d30s --latency http://你的Nginx服务器IP/测试地址

核心指标解读

表格

指标	说明	优化目标
Requests/sec	QPS，每秒处理的请求数	优化后提升 30% 以上，无错误率前提下越高越好
Latency	平均响应延迟	优化后降低 50% 以上，静态资源 < 50ms，API 接口 < 200ms
P95/P99 Latency	95%/99% 请求的最大延迟	核心优化目标，P99 延迟需低于平均延迟的 2 倍，避免长尾请求
Non-2xx or 3xx responses	错误请求数	必须为 0，高并发下出现错误说明存在瓶颈
Socket errors	套接字错误	必须为 0，出现 connect/read/write 错误说明连接队列 / 系统参数存在瓶颈

4. 调优闭环规范

1. 单次仅修改 1-2 个优化参数，避免多参数修改导致无法定位优化效果
2. 每次修改配置后，执行nginx -t验证语法，重载配置后等待 1 分钟再压测
3. 每次压测执行 3 次，取平均值，避免单次压测的偶然性
4. 记录每次优化的参数与压测结果，形成优化台账，最终沉淀最佳实践配置

---

五、常见性能瓶颈排查与故障处理

1. 高并发下 502/504 错误

• 排查方向 1 ：上游服务故障 / 超时，查看 Nginx 错误日志，确认是否是上游服务无响应，优化proxy_connect_timeout/proxy_read_timeout，增加proxy_next_upstream重试机制
• 排查方向 2 ：全连接队列溢出，执行netstat -s | grep 'listen queue'，查看 overflowed 数值持续增长，调大net.core.somaxconn与 Nginx 的listen backlog参数
• 排查方向 3 ：上游服务连接耗尽，开启 upstream 长连接复用，优化keepalive参数，避免频繁创建销毁 TCP 连接

2. TIME_WAIT 连接堆积、端口耗尽

• 核心解决 ：开启net.ipv4.tcp_tw_reuse = 1，调大net.ipv4.tcp_max_tw_buckets，缩短tcp_fin_timeout
• 辅助优化 ：开启长连接复用，减少短连接请求，调大keepalive_requests与keepalive_timeout
• 注意 ：绝对不要开启tcp_tw_recycle，NAT 环境下会导致客户端握手失败

3. Nginx CPU 占用 100%

• 用户态 CPU 过高：大概率是复杂的 rewrite 正则表达式、gzip 压缩级别过高、频繁的 SSL 握手，优化正则规则，降低 gzip 压缩级别，开启 SSL 会话复用
• 内核态 CPU 过高 ：大概率是进程频繁上下文切换、连接数过高、中断不均衡，优化 worker 进程 CPU 绑定，关闭accept_mutex，绑定网卡中断到指定 CPU 核心
• 定位工具 ：使用top定位高占用的 worker 进程，通过perf top -p 进程ID定位性能热点函数，精准定位瓶颈

4. 磁盘 IO 瓶颈导致响应缓慢

• 优化 1 ：开启访问日志缓冲buffer=64k flush=5s，关闭静态资源的 access_log，减少日志写入 IO
• 优化 2 ：开启open_file_cache，缓存静态文件元信息，减少磁盘 IO 查询
• 优化 3 ：开启sendfile+aio+directio，优化大文件读写性能，减少系统缓存占用
• 优化 4：更换 SSD 硬盘，调整 IO 调度器为 mq-deadline，提升 IO 读写效率

5. 内存占用过高 / 内存泄漏

• 排查方向 1：proxy_buffer/ssl_session_cache 配置过大，导致内存占用过高，合理调整缓冲区大小
• 排查方向 2：第三方模块内存泄漏，逐步禁用非核心模块，重启 Nginx 验证
• 排查方向 3 ：长连接超时时间过长，空闲连接占用内存，合理调整keepalive_timeout，关闭无效长连接
• 临时解决 ：平滑重启 Nginxnginx -s reload，释放内存，不影响业务请求