LNMP在Debian上如何调优

LNMP在Debian上的调优清单

一系统层优化

资源与内核
- 升级到最新稳定版并定期更新：执行 sudo apt update && sudo apt full-upgrade -y，保持内核与用户态组件的安全与性能修复。
- 文件描述符与进程限制：将软/硬限制提升到至少 65535，例如在 /etc/security/limits.conf 增加：
  - - soft nofile 65535
  - - hard nofile 65535
  - nginx soft nofile 65535
  - nginx hard nofile 65535 并在 systemd 服务单元中设置 LimitNOFILE=65535（Nginx、PHP-FPM、MariaDB）。
- 虚拟内存与I/O：适度降低 vm.swappiness（如 10–30），减少换页；使用 SSD 并合理挂载选项（如 noatime）。
- 网络栈（/etc/sysctl.conf 或 /etc/sysctl.d/99-tuning.conf）：
  - net.core.somaxconn = 65535
  - net.ipv4.ip_local_port_range = 1024 65535
  - net.ipv4.tcp_fin_timeout = 30
  - net.ipv4.tcp_slow_start_after_idle = 0
  - net.ipv4.tcp_fastopen = 3
  - net.ipv4.tcp_syncookies = 1
  - net.core.netdev_max_backlog = 65535
  - 如启用防火墙/连接跟踪：net.netfilter.nf_conntrack_max = 2097152 执行 sysctl -p 使配置生效。
安全与稳定
- 防火墙仅放行必要端口（如 80/443/22），禁用不必要服务与端口转发。
- SSH 使用密钥登录、禁用 root 远程登录、限制失败重试与空闲超时。
- 数据库安全初始化：执行 mysql_secure_installation，设置强口令、移除匿名用户、禁止远程 root、删除测试库。

二 Nginx优化

进程与连接
- worker_processes auto；在多核环境可结合 worker_cpu_affinity 做亲和性绑定（或使用 auto）。
- worker_rlimit_nofile 65535；events { worker_connections 16384; use epoll; multi_accept on; }。
传输与复用
- 开启高效零拷贝：sendfile on; tcp_nopush on; tcp_nodelay on;
- 长连接复用：keepalive_timeout 65；keepalive_requests 100000。
压缩与缓存
- 启用压缩（文本类资源收益明显）：gzip on; gzip_vary on; gzip_comp_level 6; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript text/xml application/xml+rss text/javascript;
- 静态资源缓存：location ~* .(jpg|jpeg|png|gif|ico|css|js)$ { expires 1y; add_header Cache-Control “public, immutable”; }
- 动态内容加速：设置 FastCGI 缓存或反向代理缓存，例如：
  - fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=fcgi:10m max_size=1g inactive=60m use_temp_path=off;
  - fastcgi_cache_key “$scheme$request_method$host$request_uri”; fastcgi_cache_valid 200 301 302 10m; fastcgi_cache_use_stale error timeout updating http_500;
安全与观测
- 隐藏版本：server_tokens off;
- 日志级别与采样：error_log /var/log/nginx/error.log warn; access_log off 或按条件记录以减少开销。

三 PHP与PHP-FPM优化

OPcache（建议始终开启）
- opcache.enable=1
- opcache.memory_consumption=128–256
- opcache.interned_strings_buffer=16
- opcache.max_accelerated_files=10000–50000
- opcache.validate_timestamps=0（生产）或 1（需自动重载时）
- opcache.revalidate_freq=60
- opcache.fast_shutdown=1
- JIT（PHP 8+，可选）：opcache.jit=tracing；opcache.jit_buffer_size=128M
PHP运行时
- memory_limit 依据应用调优（如 128M–512M）；max_execution_time 与 max_input_time 合理设置；cgi.fix_pathinfo=0。
- 生产环境关闭暴露信息与调试：expose_php=Off；display_errors=Off；log_errors=On。
PHP-FPM进程管理（按需选择 dynamic/ondemand）
- 估算 pm.max_children：Max children ≈ 可用内存 / 单个 FPM 进程峰值内存（含框架与扩展）。
- 示例（dynamic）：pm.max_children=50；pm.start_servers=5；pm.min_spare_servers=5；pm.max_spare_servers=35；pm.max_requests=500–1000（防内存泄漏）。
- 请求隔离与超时：request_terminate_timeout=300；rlimit_files=65535；request_slowlog_timeout=5（定位慢请求）。

四 MariaDBMySQL优化

内存与缓冲
- InnoDB 缓冲池：innodb_buffer_pool_size 设为物理内存的 50%–70%（数据库专用机可更高，留出 OS 与其他服务内存）。
- InnoDB 刷新与日志：innodb_flush_log_at_trx_commit=1（强一致）；sync_binlog=1；innodb_log_file_size=256M–1G；innodb_flush_method=O_DIRECT。
连接与会话
- max_connections 依据并发与内存评估（避免过大导致上下文切换与内存压力）；back_log 适当增大（如 512–4096）。
- skip-name-resolve=1（避免 DNS 反向解析开销，确保授权使用 IP）。
查询与索引
- 不建议依赖 query cache（在 8.0 已移除；5.7 起默认关闭），优先通过索引、SQL 改写、合理分页与缓存层优化。
- 开启并定期分析慢查询日志：slow_query_log=1；long_query_time=1；log_queries_not_using_indexes=1；使用 pt-query-digest 或 mysqldumpslow 分析并建索引。
复制与高可用（按需）
- 读写分离、主从复制、GTID、半同步复制；关键业务引入连接池（如 ProxySQL）与故障转移。

五缓存层与前端加速

对象缓存：部署 Redis/Memcached，将热点数据（会话、配置、计数器、页面片段）下沉到缓存层，降低数据库压力。
反向代理缓存：在 Nginx 前或侧部署 Varnish，对可缓存内容进行边缘缓存，动态内容通过 ESI 或应用层标记可控缓存。
全链路：启用 HTTP/2/HTTP/3（QUIC） 与 TLS 会话复用；静态资源使用 CDN 分发；启用 Brotli（若 Nginx 编译支持）或高质量 Gzip。

六监控压测与变更流程

监控与告警
- 系统与应用：Node Exporter + cAdvisor + Nginx Exporter + MariaDB Exporter → Prometheus → Grafana 可视化；关键指标包括 CPU、内存、负载、连接数、QPS、P95/P99 延迟、慢查询、缓存命中率、磁盘 IOPS/延迟。
- 进程守护：使用 Monit 或 systemd 的 Restart=on-failure 保障关键服务自恢复。
日志与追踪
- 集中化日志（如 rsyslog/ELK/Fluent Bit），对 Nginx access/error、PHP-FPM slowlog、MariaDB slow query 建立索引与可视化面板，定期审计异常与慢请求。
压测与容量评估
- 使用 wrk、ab、k6、locust 等进行渐进式压测，验证在目标并发下的 P95/P99 与错误率；结合监控找出瓶颈（CPU、I/O、连接、锁、SQL、缓存命中）。
变更与回滚
- 采用灰度/蓝绿发布；任何参数变更先在测试环境验证，变更窗口内分批滚动，保留回滚方案与回滚窗口；变更后持续观察至少 24–48 小时。

最新问答