南非VPS服务器系统不稳定如何修复?

说起系统不稳定这件事，我就想起去年帮一个做非洲电商的朋友老刘处理的那次“噩梦级”故障。他的业务主要面向南非本地和周边几个国家，服务器放在约翰内斯堡的一家数据中心。本来运行了大半年都挺稳的，结果有一天开始，服务器就像发了疯一样——动不动就自动重启，有时候一天能重启三四次。

最要命的是，每次重启都没有任何规律可循。有时候是凌晨两三点，有时候是下午业务高峰期。网站一掉线，订单就丢了，客户投诉电话一个接一个打进来。老刘那几天头发都白了不少。

我远程连上去帮他看的时候，一开始也觉得挺棘手。重启这个事吧，说大不大，说小不小。它不像彻底宕机那么明确，也不像网络不通那么简单。系统能起来，能跑一会儿，然后又倒下，如此反复。这种“半死不活”的状态，往往比彻底死机更难排查。

后来我们从日志开始，一层一层剥下去，花了整整两天才把问题彻底搞清楚。今天我就把这个过程整理出来，再结合之后处理过的几个南非VPS案例，好好聊聊系统不稳定的问题该怎么修复。

一、先搞清楚“不稳定”到底是什么样子的

在动手修复之前，有一件事特别重要——搞清楚你的“系统不稳定”到底呈现出什么症状。因为不同症状指向的根源完全不一样，搞错了方向的话，折腾半天也是白搭。

根据我的经验，南非VPS的系统不稳定通常表现为这么几种形态。

第一种是“无预警自动重启”。服务器突然就重启了，没有任何前兆。你登录控制面板一看，运行时间又从零开始计了。这种最折磨人，因为你看不到明显的错误，服务器就是突然“断气”然后又活过来。

第二种是“响应慢得像蜗牛”。服务器没有重启，但访问任何一个页面都要等好几秒，执行命令也要卡半天。这种情况通常是资源被某种东西耗尽了，CPU、内存、磁盘I/O，总有一个在满负荷运转。

第三种是“服务时好时坏”。有时候能连上，有时候连不上，像心电图一样一上一下。这种情况往往是网络层面的问题，或者是某个进程频繁崩溃又被自动拉起来。

第四种是“彻底卡死”。服务器既没重启，也没报错，但就是什么也做不了，连SSH都敲不进命令。这种情况通常需要强制重启才能恢复。

我那朋友老刘遇到的是第一种和第三种的混合体。服务器会随机重启，但重启之后又能正常运行一段时间。这种“随机性”是最难排查的，因为你不知道什么时候会触发，也不知道该盯着哪个指标看。

二、从日志入手：系统自己会告诉你答案

在处理系统不稳定问题的时候，我的第一个建议永远是——去看日志。系统出了什么事，它自己多多少少会留下一些痕迹。

对于Linux系统来说，最重要的几个日志文件都在/var/log/目录下面。

/var/log/messages是系统的大杂烩日志，各种内核消息、服务状态变化都会记在这里。如果你的服务器是因为某个严重的错误而崩溃，重启之前的那几条记录往往就是关键的线索。

/var/log/syslog和messages类似，但不同发行版可能会有些差异。Ubuntu系统偏重于用syslog，CentOS则更常用messages。

journalctl是systemd系统的日志管理工具。这个命令能把你所有分散的日志集中在一起查询，非常方便。比如你想看上次重启前的内核日志，可以执行journalctl -k -b -1，-b -1表示上一次启动。

还有一个容易被忽略的日志是/var/log/kern.log，这里面专门记录内核层面的事件。如果服务器是因为内核恐慌(Kernel Panic)或者内核某个模块崩溃导致的重启，线索大概率就藏在这里。

老刘当时是怎么找到线索的呢?他执行了journalctl --since "2 hours ago"查看最近两个小时的日志，发现在每次重启之前，都反复出现了“Out of memory”字样的记录。这说明系统在重启之前，内存已经被耗尽了，OOM Killer在疯狂杀进程。问题虽然还没完全定位，但方向已经明确了——内存不足。

三、排查内存不足的根本原因

找到了“内存不足”这个方向之后，就需要进一步搞清楚：到底是什么吃掉了内存?

Linux系统里查看内存使用情况的命令有好几个，各有各的用处。

free -h是最直观的，直接告诉你总共有多少内存、用了多少、还剩多少。但如果只是看剩余内存还不够，你还得知道是谁在用。

top或者htop可以按内存占用排序，直接看到是哪个进程在吃内存。老刘用htop看了一眼，发现MySQL的RES内存占用达到了将近4个G，而他这台VPS总共才4G内存。这就很说明问题了——MySQL几乎把整台机器的内存都吃光了。

但问题还没完。MySQL本身确实会消耗内存，但不应该把系统内存吃到触发OOM的地步。进一步检查后发现，老刘的MySQL配置里没有设置innodb_buffer_pool_size的限制，MySQL默认把缓冲池设成了物理内存的百分之七十到八十。一台4G的机器，MySQL自己就占了3G多，再跑其他服务，不死才怪。

另外还有一个隐藏的“内存杀手”——Swap空间。Swap是硬盘上的一块区域，当物理内存不够的时候，系统会把不常用的数据挪到Swap里。但如果你的Swap没配，或者配得太小，物理内存一紧张就直接触发OOM了。

老刘的VPS默认配置了512M的Swap，对一台4G内存的机器来说偏小了。后来我们把Swap调整到了2G，又给MySQL设置了内存上限，重启之后系统就稳定多了。

四、南非特有的电力问题：一个不能忽略的因素

说完了软件层面的问题，我想单独聊聊南非这个地区的一个“特色”——电力不稳定。

这个话题可能很多人在国内或者欧美用VPS的时候根本不会想到。但在南非，这是一个非常现实的问题。

南非国家电力公司Eskom长期以来面临发电能力不足的问题，时不时就会搞“拉闸限电”，南非人管这叫“负荷削减”。虽然在主要城市的数据中心通常会配备UPS和柴油发电机，但电力波动仍然可能对服务器造成影响。

具体到VPS层面，虽然你用的不是物理机，但宿主机是跑在物理机上的。如果数据中心的电力供应出现波动，比如电压瞬间跌落、频率不稳，宿主机就可能出现异常，进而导致你的虚拟机被强制重启或者迁移。

我之前遇到过这么一个案例。客户在开普敦的VPS也是频繁重启，我们把所有的软件配置都检查了一遍，确认没有任何问题。后来联系服务商，对方才告知说那一周他们所在的机房所在的片区电网电压不太稳定，虽然UPS能撑住，但电压的波动触发了部分服务器电源模块的保护机制，导致了一些虚拟机被误判为“掉电”而重启。

所以，如果你发现南非VPS的系统不稳定，在软件层面排查了一圈都没发现问题，不妨和服务商确认一下机房最近的电力状况，以及你所在的宿主机有没有被迁移过。这不是你的问题，但知道有这个因素存在，可以避免你在软件配置上做无用功。

五、DDoS攻击：南非当前正在经历的威胁

说到南非VPS的系统不稳定，还有一个不得不提的因素，就是DDoS攻击。

这不是危言耸听。根据近期的新闻报道，南非多家主流托管服务商和网络基础设施公司都遭遇了大规模的DDoS攻击。攻击流量峰值据称超过了300Gbps，导致包括Xneelo(也就是原来的Hetzner南非)、1-Grid在内的多家服务商出现间歇性服务中断。

更值得注意的是，部分攻击背后有勒索动机。Network Platforms明确表示收到了赎金要求，但拒绝支付后，攻击仍在持续。

这对普通用户意味着什么呢?如果你的VPS所在的机房或者上游网络供应商正在遭受DDoS攻击，即使你的服务器本身没有任何问题，也一样会表现出“系统不稳定”——可能是网络延迟飙升、丢包严重，也可能是完全无法访问。

那么怎么判断是不是DDoS导致的呢?

第一，看你的服务商有没有发公告。如果真的是大规模攻击，服务商通常会在官网或者状态页面发布说明。

第二，看网络流量的走势。如果你的带宽使用率突然飙升到了一个前所未有的高度，而且来源IP分布非常分散，那基本可以判断是DDoS。

第三，看访问失败的规律。DDoS攻击导致的访问失败通常是“大面积”的，而不是只有你一个人连不上。

如果你怀疑是DDoS导致的不稳定，最直接的应对方式是启用服务商提供的DDoS防护服务。很多南非的VPS提供商都提供基础级别的DDoS防护，但可能需要你主动去开启。另外，也可以考虑在前面套一层CDN或者高防IP，把攻击流量挡在外面。

六、系统配置层面的优化与修复

前面说了电力问题和DDoS攻击，这些属于“外部因素”。但大部分情况下，系统不稳定的根源还是在配置层面。下面我列几个在南非VPS上特别容易踩的坑，你可以对照着自己检查一下。

内核参数调优。Linux的默认内核参数是为通用场景设计的，在高负载或者特殊网络环境下可能需要调整。比如之前提到的连接数上限，如果你的服务需要处理大量并发连接，net.ipv4.tcp_tw_reuse、net.core.somaxconn这些参数都需要适当调大。

文件描述符限制。每个进程能同时打开的文件数量是有限制的。如果你的服务需要处理大量连接，或者需要同时读写很多文件，默认的1024很容易就不够用了。可以在/etc/security/limits.conf里修改nofile的限制。

计划任务的时间安排。很多人在配置cron任务的时候不会考虑时间分布。如果好几个繁重的任务都安排在了凌晨同一个时间点执行，比如日志分析、数据库备份、缓存清理，这些任务同时跑起来，很容易把服务器资源吃满，导致系统响应变慢甚至卡死。解决办法是把这些任务的时间错开。

防火墙规则检查。有时候系统“不稳定”的表现是某些端口突然连不上了。这可能是防火墙规则在特定的触发条件下拦截了连接。检查一下iptables或者ufw的规则，看看有没有过于激进的拦截策略。

还有一个容易被忽略的点是系统更新。有时候系统自动更新的内核版本和某些驱动不兼容，也会导致不稳定。如果你发现不稳定是在某次系统更新之后开始的，可以尝试回滚到之前的版本。

七、建立持续监控，把问题消灭在萌芽阶段

文章写到这里，我想说一句真心话。系统不稳定这个问题，最好的处理方式其实是“在它发生之前就发现它”。等服务器已经开始频繁重启了再去救火，无论如何都会造成损失。

那么怎么做到“提前发现”呢?我建议至少做这么几件事。

监控基础资源。用Prometheus、Zabbix这类工具，或者直接用云服务商自带的监控面板，盯着CPU使用率、内存使用率、磁盘I/O、网络流量这几个核心指标。不一定要搞多复杂的系统，但至少要能看历史趋势。当某个指标在一段时间内持续走高的时候，你就该警觉了——可能在不久的将来就会出事。

设置合理的告警阈值。比如说内存使用率持续超过百分之八十五超过十五分钟，就发个告警。这个阈值不能设得太低，否则会收到太多无效告警;也不能设得太高，否则等告警发出来的时候服务器可能已经挂了。

记录变更操作。很多时候系统不稳定的根源，是某次配置改动埋下的隐患。如果你养成记录每次变更操作的习惯，比如改了哪个配置文件、改了什么东西，出问题的时候就能快速回溯，缩小排查范围。

总结

南非VPS服务器系统不稳定的修复，说到底是一个“分步骤、找根源”的过程，而不是靠运气瞎蒙。

先搞清楚不稳定的具体表现是什么——是无预警重启、响应缓慢、还是服务间歇性中断。然后从日志入手，系统会在messages、syslog或者kern.log里留下线索。如果是内存相关的问题，用free、top、htop这些工具定位到具体的进程，然后再针对性地调整配置。

别忘了南非特有的外部因素。电力供应的波动会影响数据中心，进而影响你的虚拟机。DDoS攻击在南非的托管行业时有发生，如果你的VPS所在的服务商正在遭受攻击，你的服务器再稳也白搭。

配置层面，内核参数、文件描述符限制、计划任务的错峰调度、防火墙规则的合理性，这些都是值得仔细检查的地方。

最后，别等到服务器已经满身是病的时候才去治。把监控搭好，把告警配好，让问题在变大之前就被你发现。系统稳定这件事，三分靠事后修复，七分靠事前预防。