AWS EC2 t2.micro实例执行操作时无响应及连接中断问题求助

t2.micro实例出现这类问题，主要是资源瓶颈导致的，而非操作错误，具体原因和解决方向如下：

核心原因 #

1. 内存不足 #

t2.micro仅配备1GB内存，Ubuntu系统本身运行就会占用约300-500MB内存，再加上MySQL启动（默认配置至少需要200-300MB）、Docker后台进程，以及apt安装时的缓存/临时进程，很容易把内存耗尽。当内存不足时，系统会触发OOM Killer（内存不足终止进程），甚至直接导致系统无响应、SSH连接中断。

2. CPU积分耗尽 #

t2系列是突发性能实例，依赖CPU积分提供基线性能（t2.micro基线是10% CPU使用率）。当你执行安装软件、启动数据库/容器这类高CPU消耗的操作时，会快速耗尽积累的CPU积分，之后实例会被限制在基线性能，导致操作卡顿甚至系统假死。

3. 磁盘IO瓶颈（可选） #

如果使用的是默认的gp2卷，小规格实例的磁盘IOPS有限，大量安装操作或容器镜像拉取会占满IO资源，间接导致系统响应迟缓。

解决办法 #

• 升级实例规格：直接切换到t3.micro（同样在AWS免费套餐范围内，性能更稳定，无CPU积分限制）或t2.small（2GB内存），能直接解决内存和CPU瓶颈。
• 优化内存使用：
  • 修改MySQL配置文件/etc/mysql/my.cnf，降低innodb_buffer_pool_size（比如设为128MB）、key_buffer_size等参数，减少内存占用。
  • 关闭不必要的系统服务，用systemctl disable --now <服务名>禁用闲置服务。
• 缓解CPU积分问题：
  • 提前积累CPU积分：让实例在低负载下运行一段时间，积累足够积分后再执行高负载操作。
  • 切换到t3系列实例：t3使用无限模式，积分耗尽后不会被限制性能（仅超出基线的部分按小时计费，免费套餐内仍免费）。
• 优化磁盘IO：如果是gp2卷，可临时增加卷大小提升IOPS（gp2的IOPS与容量挂钩），或切换到gp3卷（可独立配置IOPS）。

内容的提问来源于stack exchange，提问作者Cgiraldov