1. 先别急着动手，看看监控#

很多人看到 CPU 飙升就急着扩容。但搞清楚问题是什么，比解决问题更重要。

我常用的第一个命令：

1
$ htop

htop 比传统的 top 更直观。一眼就能看出是哪个进程在吃资源，颜色编码也让状态更清晰。

如果 htop 不够，就上 iostat：

1
$ iostat -x 1 10

看 %util，接近 100% 说明磁盘是瓶颈。

2. 内存不是无限的#

free -h 看大概，vmstat 1 10 看细节。

如果 si 和 so 长期不为 0，说明系统在疯狂交换内存到磁盘。这时候性能会断崖式下跌。

解决办法：

• 短期：清理缓存 echo 3 > /proc/sys/vm/drop_caches
• 长期：加内存，或者优化程序内存占用

3. 网络瓶颈怎么查#

1
$ ss -s
2
$ netstat -i

看 TCP 连接数、网卡收发包的丢包率。

如果连接数长期高位，检查一下 TIME_WAIT 状态的连接：

1
$ ss -tan | awk '/^TIME_WAIT/ {++n} END {print n}'

太多 TIME_WAIT 会占用端口资源，导致新连接无法建立。

4. Systemd 服务优化#

很多人忽略了 Systemd 的资源限制功能。

在 /etc/systemd/system/你的服务.service 里加上：

1
[Service]
2
MemoryMax=512M
3
CPUQuota=80%
4
TasksMax=50

这样即使程序有内存泄漏，顶多是这个服务崩，不会把整个服务器拖垮。

5. 调优不是一次性的#

我建立了一个简单的监控脚本，每天早上 8 点发到飞书：

1
#!/bin/bash
2
date >> /var/log/daily_report.log
3
echo "CPU: $(top -bn1 | grep 'Cpu(s)')" >> /var/log/daily_report.log
4
echo "MEM: $(free -h | grep Mem)" >> /var/log/daily_report.log
5
echo "DISK: $(df -h | grep '/$')" >> /var/log/daily_report.log

然后丢到 crontab 里自动跑。

这样不用登录服务器，每天看看报告就知道健康状况。

写在最后#

服务器就跟人的身体一样。

平时不体检，等到症状明显了，往往已经是大问题了。

我这次被骂完之后，把这套监控和预报告机制搭了起来。老板说”这还差不多”。

但我知道，我只是不想让另外一个凌晨三点的自己，再面对一次监控大屏上那根垂直上升的线。

优化是无止境的。

但只要今天比昨天好一点，就够了。