目录

服务器性能优化实战：从问题发现到完美调优

背景：一次意外的性能之旅

最开始只是想看看服务器上跑着什么进程，没想到这一看，开启了一次深度的服务器性能优化之旅。

从一个简单的ps aux命令开始，我发现了一个有趣的现象：

  • MySQL占用261MB内存（25.9%）

  • Apache跑了十几个进程

  • 系统里还有一堆不知道干什么的服务

这激发了我的好奇心：这台1GB内存的小服务器，到底能压榨出多少性能？

第一阶段：系统瘦身

清理无用服务

首先发现了几个"占着茅坑不拉屎"的服务：

# Postfix邮件服务 - 我根本不需要发邮件
sudo systemctl stop postfix
sudo systemctl disable postfix

# unattended-upgrades - 自动更新服务，占内存还可能搞坏系统
sudo systemctl disable unattended-upgrades

# networkd-dispatcher - 网络事件处理，静态IP用不着
sudo systemctl disable networkd-dispatcher

这一轮操作下来，释放了约22MB内存。看起来不多，但这只是开始。

数据库大扫除

用phpMyAdmin看了看数据库，发现了两个巨无霸：

  • pro库：714MB

  • geolbs库：681MB

仔细一看，都是些多年前的测试数据和垃圾数据。一番清理后：

优化前：1.7GB
优化后：475MB
释放空间：943MB！

这个效果立竿见影。重启MySQL后，内存占用从261MB降到了182MB，节省了79MB内存。

第二阶段：性能测试

压测神器：Apache Bench

想知道服务器真实性能，最直接的方法就是压测。用link-server作为压测机，对小程序API进行测试：

# 基础测试
ab -c 5 -n 50 https://xdjsq.codekissyoung.com/api/test

第一次结果让我皱眉：

  • 吞吐量：19.68 RPS

  • 平均响应时间：254ms

  • SSL握手时间：188ms

188ms的SSL握手时间？这也太夸张了！

SSL性能调优：从瓶颈到飞跃

问题出在SSL配置上。经过一番调研，发现了几个关键优化点：

# 延长SSL会话复用时间
SSLSessionCacheTimeout 600  # 从300改为600秒

# 确保Keep-Alive启用
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

优化后再测试，效果惊人：

优化前：19.68 RPS, 254ms响应
优化后：43.94 RPS, 114ms响应
性能提升：123%！

更重要的是，Keep-Alive生效后，大部分请求的连接时间变成了0ms，SSL握手得到了完美的复用。

高并发测试：寻找极限

既然优化效果这么好，那就测试一下极限在哪里：

# 20并发测试
ab -c 20 -n 200 -k https://xdjsq.codekissyoung.com/api/test
结果：96.14 RPS, 208ms响应

# 50并发测试  
ab -c 50 -n 500 -k https://xdjsq.codekissyoung.com/api/test
结果：107.67 RPS, 464ms响应

107 RPS的HTTPS性能，对于一台1GB内存的小服务器来说，这个成绩相当不错了！

第三阶段：架构思考

MySQL分离的诱惑与现实

看着182MB的MySQL内存占用，我动了"歪脑筋"：能不能把数据库迁移到link-server上？

理论很美好：

  • 释放182MB内存

  • 数据库独立scaling

  • 架构更清晰

但现实很骨感：

# 测试两台服务器延迟
ping 120.77.216.243
结果：42ms往返延迟

42ms的网络延迟，对于数据库访问来说还是有点高的。特别是考虑到：

  • 数据库有475MB，不全在内存缓存中

  • 每次查询都要走网络，延迟累积

  • 网络故障会影响整个系统可用性

经过权衡，决定保持单机架构。毕竟当前性能已经很好，"不要修复没有破坏的东西"是最明智的选择。

Apache配置的艺术平衡

发现Apache使用的是prefork MPM + mod_php，这是内存占用较高但最稳定的组合。

理论上可以切换到worker或event MPM来节省内存，但考虑到：

  • 需要重新配置PHP-FPM

  • 25+个虚拟主机需要重新测试

  • 稳定性风险较高

  • 当前性能已经满足需求

最终选择保持现有架构不变，这体现了一个重要的运维原则：稳定性优于极致性能。

关键收获：优化的哲学

1. 数据驱动的决策

每一个优化决策都基于具体的数据：

  • 内存占用分析：ps aux --sort=-%mem

  • 磁盘使用检查：du -sh

  • 性能测试验证：ab压测

  • 网络延迟测量：ping

没有测量就没有优化，盲目调优往往适得其反。

2. 收益递减定律

优化过程中明显感受到收益递减：

  • 数据清理：释放943MB，效果显著

  • MySQL配置：节省79MB，价值很高

  • SSL优化：性能提升123%，立竿见影

  • 微调服务：节省几MB，意义不大

把精力花在影响最大的地方，而不是纠结于细枝末节。

3. 稳定性vs性能的平衡

面对多个优化选择时，始终把稳定性放在第一位：

  • 保持Ubuntu 18.04而不升级（避免兼容性问题）

  • 保持prefork MPM而不切换（避免配置复杂化）

  • 保持单机架构而不分离（避免网络依赖）

这些决策看起来"保守"，但对于生产环境来说是最明智的。

最终成果：性能的蜕变

优化前后对比

指标优化前优化后改善
磁盘占用1.7GB475MB-72%
MySQL内存261MB182MB-30%
HTTPS性能19.68 RPS107.67 RPS+447%
可用内存~300MB478MB+59%

系统承载能力评估

基于107 RPS的性能，这台服务器可以支撑：

  • 轻量小程序：3000-5000并发用户

  • 日活用户：20,000-50,000（假设5-10%同时在线）

  • 每分钟请求：6400个请求

对于我的德州扑克计分器小程序来说，这个性能完全够用了。

写在最后：运维的智慧

这次优化过程让我深刻体会到，好的运维不是追求极致的参数，而是在性能、稳定性、可维护性之间找到最佳平衡点。

有时候，知道什么时候停止优化，比知道怎么优化更重要。

当系统已经满足业务需求，运行稳定时，保持现状往往比继续折腾更明智。毕竟，一台能稳定运行、性能良好的服务器，胜过十台被过度优化搞崩的服务器。

PS：这次会话最有价值的不是具体的优化技巧，而是整个分析和决策的思维过程。数据驱动、风险评估、收益权衡——这些才是运维工作的核心竞争力。

2025-08-29 记录