![如何知道我的 nginx 是否健康?](https://linux22.com/image/601094/%E5%A6%82%E4%BD%95%E7%9F%A5%E9%81%93%E6%88%91%E7%9A%84%20nginx%20%E6%98%AF%E5%90%A6%E5%81%A5%E5%BA%B7%EF%BC%9F.png)
我在 EC2(m1.small)上运行 nginx 以终止 SSL。
我在 Ubuntu 上使用 2 个 worker,使用最新的 nginx(稳定版),网络吞吐量大约为2Mbps系统平均负载约为2 至 3。
我想知道这个系统现在是否运行良好,
例如
- 队列长度是多少(我知道 nginx 可以处理大量并发请求,但我的意思是在请求被服务之前,有多少个请求需要等待才能被服务)
- 给定请求的平均排队时间是多少。
我想知道,因为我的 nginxCPU 受限(例如由于 SSL),我需要升级到更快的实例。
我当前的 nginx 状态
Active connections: 4076
server accepts handled requests
90664283 90664283 104117012
Reading: 525 Writing: 81 Waiting: 3470
答案1
答案2
要检查 I/O 繁重的进程,请尝试安装iotop
:
apt-get install iotop
它需要内核中的 i/o 核算支持,Ubuntu 10.04 或更高版本中提供该支持。
如果你发现 nginx 受 I/O 限制,请尝试检查是否确实需要访问日志记录(在如此大量的请求中,这可能是瓶颈)。禁用访问日志非常简单:
access_log /dev/null crit;
供参考
access_log off;
不会这样做(nginx 将写入名为 off 的文件)。
如果你需要日志记录,实施传输策略(例如每天对日志进行一次日志轮转,并通过 rsync、scp 或其他方式将轮转后的日志发送到远程位置)并尝试写入实例存储(默认情况下安装在 /mnt 中)。实例存储由服务器本地磁盘支持,速度可能更快(尽管不能保证),但实例关闭时其数据会丢失,因此需要日志传输策略。
答案3
如何知道我的 nginx 是否健康?
检查系统指标,了解是否遇到了性能瓶颈,如果是,则确定瓶颈在哪里。
对于 m1.small 来说,2mbps 绝对很慢。我从 t1.micro 实例中获得了比这快得多的速度。检查 iotop 和 htop 以查看您的系统正在做什么。听起来您的进程中某个地方存在严重的瓶颈。此实例及其卷的 CloudWatch 指标也可能有帮助。
如果您正在运行动态页面(PHP、Perl、Ruby),可能存在一些未优化的代码导致速度变慢。
如果您没有看到主机上的 CPU 或 IO 瓶颈,那么如果堆栈中有任何其他系统,则问题可能出在另一层。
需要考虑的一件事是使用 ELB 进行 SSL 终止(以及负载平衡)以分散负载。它们并不昂贵,而且可以卸载足够的负载(假设 SSL 是罪魁祸首),从而以比增加实例大小更便宜的价格提高性能。将您的网站挂在 ELB 上还可以为您提供更多灵活性,让您可以扩展和管理网站。
答案4
并没有真正回答问题,但是......
EC2 小型实例的问题在于,您无法获得 100% 的 CPU 时间,只能获得突发时间。一旦您的实例开始持续占用 CPU,就会受到限制。
理想情况下,负载不应超过 2.0。由于小型实例只有一个 CPU,因此任何高于 1.0 的负载都意味着您已经有一半的进程在等待可用的 CPU 片。中型实例应该足够了。
一篇解释如何测量系统负载的好文章:http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages