昨天我的 Amazon Web Service 实例运行正常，但今天早上它变得很慢。我在网上搜索了相关内容，发现我可以重启我的 Amazon Web Service 实例来提高性能，所以我重启了我的实例。
但从那时起，它变得越来越慢，有时甚至无法访问它，如果我重新启动我的 mysqld，它就会开始工作，但即使是一个简单的查询也会花费很多时间。我正在使用 Amazon Web Service 免费套餐 EC2。重启后我是否错过了什么？
答案1
有许多因素可能导致 EC2 实例（或任何系统）运行缓慢。
CPU 使用率。CPU 使用率越高，处理新线程和进程的时间就越长。
可用内存。您的系统需要可用内存来处理线程、创建新进程等。您有多少可用内存？
可用磁盘空间。当系统驱动器上的文件系统的可用磁盘空间不足时，操作系统往往会崩溃。您有多少可用磁盘空间？
网络带宽。您的实例的平均输入/输出字节数是多少？
当我看到某个 EC2 实例运行缓慢时，我会暂时将其增加一两个实例大小。然后我重新测量。如果我看到性能大幅提升，那么我就可以肯定该实例超载了。接下来，我会尝试确定 CPU、内存等哪个因素是罪魁祸首。
Amazon 有 CloudWatch，它可以为您提供除可用磁盘空间之外的所有内容的监控（您可以为实例添加代理来监控此指标）。这还可以帮助我快速查看实例的运行情况。
总的来说，我发现，除非网络流量很少，否则 T2.nano 或 T2.micro 上的 Web 服务器和 MySQL 效果并不是很好。
如果您的平均 CPU 利用率为 20%，那么 t2.micro 就太小了。t2.small 具有足够的 CPU 积分，因此 CPU 利用率可以达到 20%。
例如，t2.small 实例以每小时 12 个 CPU 积分的速度持续接收积分。此功能提供相当于 20% CPU 核心的基准性能。如果实例在任何时候不需要收到的积分，它会将其存储在其 CPU 积分余额中长达 24 小时。如果您的 t2.small 需要突增到超过 20% 的核心，它会从其 CPU 积分余额中提取以无缝处理这种激增。随着时间的推移，如果您发现您的工作负载需要比您拥有的更多的 CPU 积分，或者您的实例没有保持正的 CPU 积分余额，我们建议使用更大的 T2 大小，例如 t2.medium，或固定性能实例类型。