☰

AWS ELB 延迟问题

tag-icon • tag-icon amazon-ec2 amazon-web-services amazon-elb amazon-rds
AWS ELB 延迟问题

我有两台 c3.2xlarge EC2 机器，均位于 us-west-2a AZ，均带有 Ubuntu 环境。两台机器都包含来自 AWS RDS (db.r3.2xlarge) 的 mySQL 数据库的相同代码。两个实例都添加到 ELB。两台机器都有一个 cron 计划，每天运行两次。

ELB 已配置为一旦阈值超过 5.0 就会发出警报。两个实例的 CPU 利用率平均为 30-50。在高峰时段，一两分钟内达到 100%，然后恢复正常。但 ELB 每天会不断发出三次警报。此时，两个实例都

CPU     - ~50%
Memory  - total - 14979
          used  - ~6000
          free  - ~9000
RDS CPU - ~30%
          Connections - 200 to 300 /5,000

根据这个https://aws.amazon.com/premiumsupport/knowledge-center/elb-latency-troubleshooting/我没有发现实例有什么问题。但延迟仍然达到峰值，并且两个实例都无法响应。

到目前为止，我只是从负载均衡器中删除一个实例，重新启动 Apache，然后重新加载它，并对其他实例执行相同操作。这完美地完成了工作，实例和 ELB 在接下来的 6-10 小时内运行良好。但这是不能接受的，因为每天需要两三次照顾服务器，需要重新启动它。

我需要知道是否存在任何问题或者需要采取什么步骤来解决这个问题。

潜伏

记忆

Apache 服务器状态包含太多此类信息 (~200/250 个进程)：

7-0 23176   1/2373/5118 C   30.95   3986    0   0.0 7.01    15.78   127.0.0.1   ip-xxx-xxx-xxx-xxx.us-west-2.comp   OPTIONS * HTTP/1.0

答案1

中央处理器利用率（%）不是关键，关键是CPU平均负载（队列）和网络指标、apache 指标、缓冲区等。负载均衡器是非常简单的设备，问题，其中 LB 涉及架构通常与 ELB 无关，而是与其他事物的工作方式有关。

要查看问题出在哪里，您必须执行以下步骤：

  • 检查 Apache 是否响应本地请求，如果没有，问题就不在于 ELB
  • 检查 apache 工作进程的状态（即 mod_status），相应地调整 MPM 设置
  • 检查 CPU 平均负载，如果平均负载超过 CPU 数量，并且 iowait 增加，则表示 IO 存在问题
  • 检查是否启用了连接持久性，以及是否确实需要它，如果你确实在需要访问同一 Web 实例的 Web 服务器上使用会话
  • 检查 apache 的 keepalive 设置，禁用它或设置非常低的超时值
  • 检查实例上是否启用了 iptables，以及 nf_conntrack_max 和 nf_conntrack_count 内核参数是否配置了更高的值。如果不需要，请禁用它，并且根本不要加载模块
  • 使用 http 请求对单个实例进行压力测试（提示：ab、jmeter）

  • 检查并相应地调整内核参数：

    net.core.wmem_max
net.core.rmem_max
net.core.netdev_max_backlog

net.core.somaxconn
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
net.ipv4.tcp_no_metrics_save
net.ipv4.tcp_timestamps
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_synack_retries
net.ipv4.tcp_keepalive_time

net.netfilter.nf_conntrack_acct
net.netfilter.nf_conntrack_generic_timeout
net.netfilter.nf_conntrack_tcp_timeout_syn_sent
net.netfilter.nf_conntrack_tcp_timeout_syn_recv
net.netfilter.nf_conntrack_tcp_timeout_established
net.netfilter.nf_conntrack_tcp_timeout_fin_wait
net.netfilter.nf_conntrack_tcp_timeout_close_wait
net.netfilter.nf_conntrack_tcp_timeout_last_ack
net.netfilter.nf_conntrack_tcp_timeout_time_wait
net.netfilter.nf_conntrack_tcp_timeout_close
net.netfilter.nf_conntrack_tcp_timeout_max_retrans
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged
net.netfilter.nf_conntrack_icmp_timeout
net.netfilter.nf_conntrack_events_retry_timeout
net.ipv4.netfilter.ip_conntrack_generic_timeout
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans
net.ipv4.netfilter.ip_conntrack_icmp_timeout
net.netfilter.nf_conntrack_tcp_loose
net.netfilter.nf_conntrack_max net.nf_conntrack_max
net.netfilter.nf_conntrack_count

此后 Apache 没有响应？这根本不是 ELB 的错。

相关内容