从这两张监控图可以看出，服务器在大约上午 10:30 前后经历了一次明显的负载变化：

---

1. 图表解读

• CPU 使用率

  • 从凌晨到上午约 10:00 前，CPU 基本处于 0–2% 的闲置状态。
  • 10:00–14:00 之间，CPU 利用率逐步攀升，多次冲击 30%–50% 的区间，最高达到约 52.6%。

• 内存使用率

  • 同期内存一直保持在 ~39–40% 左右。
  • 上午约 10:30 开始，内存使用率突然跃升至 60%、70%，随后逐渐爬升至 99.2% 的峰值。

---

2. 可能原因

1. 新进程/服务启动

   • 某个定时任务、容器或后台服务在 10:30 左右启动，短时间内占用了大量内存。

2. 内存泄露或缓存

   • 应用（如 Java、Python 后台进程）未正确释放对象，导致内存逐渐耗尽。
   • 数据库或缓存（如 Redis、MySQL）缓存设置过大。

3. 缺少 Swap

   • 如果未配置 swap，当物理内存耗尽时，系统会直接 OOM（Out-Of-Memory），表现为内存占满并伴随进程被杀。

4. 日志/文件写入暴增

   • 大量日志写入或文件缓存也会暂时占满内存。

---

3. 排查步骤

1. 实时进程监控

   # 查看内存占用前十的进程
   ps aux --sort=-%mem | head -n 15# 交互式查看（安装 htop 更直观）
   top
   # 或
   sudo apt-get install -y htop && htop
   

2. 内存与 swap 情况

   free -h
   

   • 确认物理内存、swap 是否被用满。
   • 如果没有 swap，可考虑添加。

3. 查看系统日志

   # OOM 杀进程记录
   dmesg | grep -i oom
   journalctl -p err -n 50
   

4. 回溯定时任务

   • 检查 /etc/crontab、/var/spool/cron 下是否有新任务在此时段执行。

5. 应用自身日志

   • 对应服务（如你的 Web 应用、数据库）日志目录，查找异常报错或 GC 信息。

---

4. 解决方案

1. 短期应急

   • 杀掉占用过高的进程：

     kill -9 <pid>
     

   • 重启内存泄漏进程或容器服务：

     systemctl restart your-service
     

2. 配置 Swap 分区／文件

   sudo fallocate -l 2G /swapfile
   sudo chmod 600 /swapfile
   sudo mkswap /swapfile
   sudo swapon /swapfile
   # 添加到 /etc/fstab 使重启后自动启用
   echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
   

3. 优化应用配置

   • 减小 JVM/Xmx、Python 缓存等内存上限；
   • 调整数据库缓存（MySQL 的 innodb_buffer_pool_size、Redis 的 maxmemory）；

4. 横向或纵向扩容

   • 增大实例规格（更大内存）；
   • 部署多实例，做负载均衡，分担内存压力。

5. 监控与报警

   • 在华为云监控中为内存使用率 ≥ 80% 设定告警，及时干预；
   • 定期审查定时任务与日志大小，避免突增。

---

5. 与 SSH 连接问题的关联

• 内存被打满时，系统可能触发 OOM，杀掉包括 sshd 在内的关键进程，导致 VS Code 无法通过 SSH 连接，但 Navicat（连接数据库）看似正常，因为数据库进程仍在运行。

• 先解决内存占满，再尝试重启 sshd：

  sudo systemctl restart sshd
  

---

下一步建议：先通过 ps aux/top 找出“吃”内存最厉害的进程，并进行杀进程或重启；然后按需配置 swap 并优化服务内存参数；最后视业务情况决定是否扩容。