我在EC2（m1.small）上运行一个nginx进行SSL终止。
我在Ubuntu上使用了两名工作者，最新的nginx（稳定版），networking吞吐量约为2Mbps ，系统平均负载约为2-3。
我想知道现在这个系统是否健康，
例如
我想知道，因为如果我的nginx是CPU有限 （例如由于SSL），我将需要升级到更快的实例。
我目前的nginx状态
Active connections: 4076 server accepts handled requests 90664283 90664283 104117012 Reading: 525 Writing: 81 Waiting: 3470 configurationnginx状态插件并安装collectd来收集系统性能数据。 这是一个非常轻量级的守护进程，意味着它需要系统资源。 有nginx监控插件 ： 插件：nginx ，当然collectd可以监控整个其他系统的性能数据。
就collectd ，只是性能数据的收集器（将其存储在RRD DB中），需要一个用于显示数据的工具。 我用CGP很舒服… git版本是好的。 CGP是一个PHP应用程序，因此只有当你看图时，它才会吃你的CPU。
示例图： Nginx_connections_and_requests.png
顺便说一句，亚马逊的EC总是比别人慢很多，尤其是存储。 这可能是更高负载的根源。
要检查I / O繁重的进程，请尝试安装iotop ：
apt-get install iotop
它需要内核中的I / O会计支持，这在Ubuntu 10.04或更高版本中存在。
如果您发现nginx是I / O绑定的，请尝试检查您是否确实需要访问日志logging（这可能是此类大量请求的瓶颈）。 禁用访问日志非常简单：
access_log /dev/null crit;
FYI
access_log off;
将不会（nginx将写入一个名为off的文件）。
如果你需要日志logging，实现一个运输策略（例如每天login一次日志，并通过rsync，scp或其他方式将轮转的日志发送到远程位置），然后尝试写入实例存储（默认安装在/ mnt中）。 实例存储由服务器本地磁盘支持，可能会更快（虽然这不能保证），但实例closures时数据丢失，因此需要日志传送策略。
如何知道我的nginx是否健康？
检查系统度量标准，看看你是否遇到性能瓶颈，如果是的话; 确定它在哪里。
2mbps肯定是一个m1.small缓慢。 我已经从我的t1.micro实例获得了更多。 检查iotop和htop，看看你的系统在做什么。 听起来你的程序在某个地方存在一个令人讨厌的瓶颈。 此实例的CloudWatch指标以及卷数量也可能有所帮助。
如果您正在运行dynamic页面（PHP，Perl，Ruby），那么可能会有一些未经优化的代码导致速度放慢。
如果您没有看到主机上的CPU或IO瓶颈，那么如果堆栈中有其他系统，则问题可能出现在另一层。
需要考虑的一件事就是使用ELB来实现SSLterminal（以及负载平衡）来分散负载。 它们并不是非常昂贵的，它可能会卸载足够的空间（假设SSL被指责）来帮助性能比实例大小更便宜。 把你的网站挂在ELB上也会给你如何扩展和pipe理网站的灵活性。
由于您使用的是只有1个计算单元的ec2 small，所以2〜3的loadavg太高。 系统指标将提供比您从nginx提供的信息更有用的信息。 相反，这些指标真的没有任何帮助…
一般来说，您也可以通过阅读有关平均负荷的其他问题来获益，以更好地理解其意义和重要性。
不是真的回答这个问题，但是…
EC2的小实例的问题是，你没有100％的CPU可用时间，只有突发。 一旦您的实例开始保持CPU一直繁忙，它就会受到限制。
理想情况下，你不应该达到负载> 2.0。 由于小型实例只有一个CPU，任何大于1.0的负载意味着您已经有一半的进程正在等待可用的CPU片。 一个中等的实例应该足够了。
一篇很好的文章解释如何衡量系统负载： http : //blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
如果你的顶部显示nginx是唯一的吃CPU的过程，你的实例types是m1.small，那肯定意味着nginx处于BAD状态。 一定要closuresgzip压缩，我也build议添加SPDY补丁http://nginx.org/patches/spdy/README.txt（firefox和chrome支持SPDY），这将大大增加SSL页面的加载时间。