早上醒来，习惯性打开自己的博客，准备写篇文章。按下回车的那一刻，我瞬间懵了——页面只剩空白框架，完全没有内容。我的博客架构采用 Golang + Nuxt + MySQL + Redis，多年开发经验让我立刻冷静分析：前端能正常加载，大概率是接口或数据库出了问题。
马上 SSH 连接服务器排查，Nuxt、Golang 后端服务均运行正常，但日志里一行报错直接锁定问题：
MySQL 连接失败: dial tcp 127.0.0.1:3306: connect: connection refused
MySQL 直接挂了。临时重启数据库后网站恢复访问，但治标不治本，必须深挖根源，彻底解决隐患。
一、从 MySQL 日志定位异常
查看数据库日志，我发现几个关键现象：
- 日志反复出现
MySQL Server - start - 频繁触发
XA crash recovery崩溃恢复 - 进程 PID 不断变化
典型问题：MySQL 被系统强制杀死 → 自动重启 → 再次被杀 → 循环崩溃。
二、层层排查，锁定两大元凶
服务器 MySQL 异常，通常只有4种原因：内存不足被 OOM 杀死、工具自动重启、配置错误、磁盘空间爆满。
执行命令排查内存：
dmesg -T | grep -i "out of memory"
果然查到 Out of memory 记录，数据库因内存不足被系统杀掉。
进一步检查磁盘，发现数据盘使用率高达92%，日志疯狂堆积，双重压力直接压垮服务器。
排除工具重启、配置错误等因素后，确定核心问题：2G 低配服务器内存紧张，无 Swap 兜底；系统日志无管控，撑满磁盘空间。
三、动手修复，长效优化
1. 补齐 Swap 虚拟内存，兜底内存溢出
我的服务器仅2G物理内存，同时跑多个服务，却没有配置 Swap 分区。
Swap 就是 Linux 的虚拟内存，用硬盘空间充当备用内存，是小内存服务器的保命配置。
一键创建4G Swap 分区：
# 创建并启用Swap
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 开机自动挂载
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# 调整内存使用策略
echo "vm.swappiness=60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
配置完成后，内存资源得到兜底，再也不会因瞬间峰值杀死 MySQL。
2. 清理磁盘，限制日志大小
根目录磁盘使用率高达90%，元凶是 /var/log 日志疯狂堆积，仅 journal 日志就占3G。
批量清理冗余日志，永久限制日志占用：
# 清理旧压缩日志
sudo find /var/log -name "*.gz" -delete
# 清理运行日志
sudo truncate -s 0 /var/log/*.log
# 限制日志最大占用
sudo journalctl --vacuum-size=100M
修改配置文件，永久约束日志大小，杜绝后续磁盘爆满问题。
四、复盘总结
这次深夜宕机给我狠狠上了一课！
很多个人站长都在用2G低配服务器，看似稳定运行，实则暗藏致命隐患。Swap 分区不能省、系统日志必须管控，内存溢出、磁盘爆满，足以让整个服务一夜崩塌。
运维无小事，细节决定稳定性。后续我会常态化巡检服务器资源，定期清理冗余文件，守住服务平稳运行的底线。
评论 (0)