☰

如何知道我的 nginx 是否健康？

tag-icon • tag-icon nginx amazon-ec2 web-server performance performance-tuning
如何知道我的 nginx 是否健康？

我在 EC2（m1.small）上运行 nginx 以终止 SSL。

我在 Ubuntu 上使用 2 个 worker，使用最新的 nginx（稳定版），网络吞吐量大约为2Mbps系统平均负载约为2 至 3。

我想知道这个系统现在是否运行良好，

例如

  1. 队列长度是多少（我知道 nginx 可以处理大量并发请求，但我的意思是在请求被服务之前，有多少个请求需要等待才能被服务）
  2. 给定请求的平均排队时间是多少。

我想知道，因为我的 nginxCPU 受限（例如由于 SSL），我需要升级到更快的实例。

我当前的 nginx 状态

Active connections: 4076 
server accepts handled requests
 90664283 90664283 104117012 
Reading: 525 Writing: 81 Waiting: 3470

答案1

配置nginx状态插件并安装收集收集系统性能数据。就其所需的系统资源而言，它是一个非常轻量级的守护进程。这里有用于 nginx 监控的插件：插件：nginx当然还collectd可以监控整个其他系统的性能数据。

就性能数据收集器（将其存储在 RRD DB 中）而言collectd，需要一个显示数据的工具。我对此很满意慢性粒细胞白血病... git 版本没问题。CGP是一个 PHP 应用程序，因此仅当您查看图表时它才会消耗您的 CPU。

示例图：连接和请求

顺便说一句，Amazon EC 总是比其他产品慢很多，尤其是在存储方面。这可能是负载较高的根源。

答案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

相关内容