网站访问出现卡顿，单靠感觉调整配置往往事倍功半。更稳妥的做法是先压测、再定位、后优化，用数据判断瓶颈出现在 Web 层、应用层还是数据库层，再针对性调整 Nginx（1Panel 网站默认基于 OpenResty）与数据库参数。本文整理一套可复用的排查与优化思路。

一、压测前先明确三件事

• 明确目标指标：是关注吞吐量（QPS/RPS）、平均响应时间，还是 P95/P99 尾延迟、错误率。不同目标对应的优化方向并不相同。
• 准备可回滚的环境：调整 Nginx 与数据库参数前，先通过 1Panel 的备份功能或快照保存当前配置，避免改错后无法快速恢复。
• 保证压测环境尽量干净：压测机与被压服务器分离，避免压测工具自身抢占 CPU 影响结论。生产环境做压测需评估影响，建议在低峰期或独立测试环境进行。

二、压测工具与分层施压

常用工具包括 wrk、hey、ab、JMeter、Locust 等。建议按“由轻到重”的顺序逐级加压，而不是一上来就打满，便于观察拐点出现的位置：

1. 低并发（如个位数并发）确认功能正常、无错误响应。
2. 阶梯增加并发，记录每个档位的响应时间与错误率。
3. 找到响应时间明显上升或错误率抬头的临界点，这就是瓶颈开始暴露的区间。

示例（仅演示参数含义，具体数值按实际环境设定）：

• wrk -t4 -c100 -d60s https://example.com/：4 个线程、100 个连接、持续 60 秒。
• 对比测试时，应分别压测静态资源、纯动态页面与含数据库查询的接口，从而区分瓶颈层级。

三、判断卡顿节点在哪一层

压测过程中同步采集服务器指标，常见对应关系如下：

• CPU 持续高位、负载高：可能是 PHP/Node 等应用进程计算密集，或 Nginx 压缩、TLS 握手开销较大。
• 内存吃紧、出现 swap：应用或数据库缓存不足，系统开始换页，延迟会明显抖动。
• 磁盘 IO 等待高：数据库写入、日志刷盘、临时表落盘等是常见原因。
• 网络带宽跑满或连接数堆积：多为静态资源未压缩、未缓存，或连接复用不足。
• Nginx 错误日志出现 upstream timed out、连接被拒绝：瓶颈通常在后端应用或数据库，而非 Nginx 本身。
• 数据库慢查询增多、连接数接近上限：问题集中在 SQL 与数据库配置层面。

在 1Panel 中可结合容器资源监控、网站日志、数据库状态等入口查看上述信息；系统层面的 top、vmstat、iostat、ss 等命令可作为补充。

四、Nginx（OpenResty）侧常见优化方向

1. 进程与连接能力

• worker_processes 通常设为 auto，与 CPU 核数匹配；worker_connections 需与进程数、系统文件描述符上限一并考虑，避免只改一项。
• 检查系统级 ulimit -n 与内核参数（如 somaxconn、tcp_max_syn_backlog），确保 Nginx 配置不被系统上限卡住。

2. 连接复用与超时

• 开启 keepalive，并为 upstream 配置连接池，减少反复建立连接的开销。
• 合理设置 proxy_connect_timeout、proxy_read_timeout、send_timeout，避免慢请求长期占用 worker。

3. 传输与缓存

• 对文本类资源启用 gzip（或 Brotli，若模块已编译），注意不要对已压缩格式重复压缩。
• 为静态资源设置合理的 expires 与 Cache-Control，减少回源请求。
• 开启 sendfile、tcp_nopush 等文件传输相关选项。

4. 日志与缓冲区

• 高并发下适当调整 client_body_buffer_size、proxy_buffer_size 等缓冲区，减少磁盘临时文件写入。
• 高频写入的访问日志可考虑缓冲或按需关闭，降低 IO 压力。

在 1Panel 中，网站的 Nginx/OpenResty 配置文件通常可在对应网站的“配置文件”入口查看与修改，改动后需重载服务使配置生效。不同版本界面位置可能略有差异，请以官方文档与当前面板为准。

五、数据库侧常见优化方向

1. 先看慢查询，再谈参数

• 开启慢查询日志，定位执行时间长、扫描行数多的语句。
• 用 EXPLAIN 检查执行计划，重点关注是否命中索引、是否出现全表扫描与临时表排序。
• 补齐或调整索引往往比调参数更直接有效；同时注意避免索引过多拖慢写入。

2. 连接与线程

• max_connections 需结合应用侧连接池大小设置，应用池过大也会耗尽数据库连接。
• 关注连接失败、连接等待等状态指标，而不是只看“连接数是否接近上限”。

3. 缓冲与缓存

• InnoDB 缓冲池（innodb_buffer_pool_size）是内存分配的重点，应在扣除系统与其他服务占用后，按实例规格合理分配，不宜盲目占比过高。
• 关注临时表、排序缓冲区相关参数，避免大量磁盘临时表。

4. 持久化与日志

• 了解 innodb_flush_log_at_trx_commit 等参数在数据安全与写入性能之间的取舍，生产环境调整前需评估可接受的风险。
• 慢查询日志、错误日志的容量与轮转策略也要一并规划，防止日志占满磁盘。

1Panel 的数据库模块提供状态查看、配置调整与备份恢复等能力，参数建议逐项修改并观察效果，避免一次性改动多个变量导致无法归因。

六、优化后必须回归验证

1. 用与优化前一致的压测参数复测，对比响应时间分布与错误率。
2. 连续观察一段时间，确认内存、连接数、慢查询没有新的异常。
3. 保留配置版本记录，注明每次改动的原因，便于后续回溯。

七、写在最后

压测的价值不在于跑出一个好看的数字，而在于把“卡顿”这个模糊感受拆解成可度量的指标，并定位到具体环节。先定位、再调整、后验证，Nginx 与数据库的调优才能稳定生效，也更容易在业务增长时持续复用这套方法。