AWS EC2 t2.micro实例运行Python程序时崩溃冻结问题咨询

• 内存资源排查
  t2.micro仅配备1GB内存，远低于多数本地机器。可以通过以下方式定位：

  • 运行free -m查看空闲内存余量；程序运行时用top或htop实时监控内存占用趋势；
  • 安装AWS CloudWatch Agent，开启内存指标监控，查看是否有内存耗尽的峰值；
  • 排查Python程序是否存在内存泄漏：比如未关闭的文件/网络句柄、无限增长的缓存容器（列表/字典），可以用memory_profiler工具逐行分析内存占用。

• CPU积分节流问题
  t2系列实例采用CPU积分机制，持续高CPU负载会耗尽积分触发节流，导致实例响应缓慢甚至冻结：

  • 用top查看CPU使用率，同时在CloudWatch中查看CPUUtilization和CPUCreditBalance指标，确认是否积分耗尽；
  • 若确认为积分问题，可切换至无积分限制的t3.micro实例，或优化程序的CPU密集逻辑（比如改用异步采集、批量数据处理）。

• 磁盘空间耗尽
  t2.micro默认根卷容量通常为8GB，容易被日志、临时文件占满：

  • 执行df -h检查磁盘使用率；
  • 清理无用日志、临时文件，或扩大EBS卷容量；若程序写入大量缓存文件，需优化缓存策略。

• 网络栈阻塞
  多源数据采集可能产生大量并发网络连接，导致实例网络栈耗尽：

  • 用netstat -anp查看连接状态，是否存在大量TIME_WAIT或未释放的ESTABLISHED连接；
  • 检查EC2安全组、NACL是否限制了出站流量，导致程序因等待网络响应而阻塞，进而占用过多系统资源。

• 程序逻辑异常
  本地与EC2环境差异（依赖库版本、系统时区、环境变量）可能引发死锁或无限循环：

  • 给程序添加详细日志，记录关键步骤的执行状态与耗时；
  • 用strace跟踪程序的系统调用，定位是否卡在某个阻塞操作上；
  • 检查多线程/多进程代码是否存在死锁，比如共享资源未正确加锁。

• 系统级错误
  查看系统日志定位底层问题：

  • 检查/var/log/messages或/var/log/syslog，是否有OOM Killer（内存不足时系统自动杀进程）记录、磁盘IO错误或内核panic信息；
  • 尝试更换一台同类型EC2实例，排除硬件故障导致的冻结。

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