服务器 Gind.cn
  1. 服务器 Gind.cn
  3. AWS ELB延迟问题
Intereting Posts
哪个AWS Ubuntu映像具有交换分区预configuration？ OSSEC – 单个DELL刀片上的多个虚拟机（XenServer Hypervisor） 从外部暴露网站 为CDN使用不同的DNS服务器 列出第三方WMI提供程序之前重新生成存储库 使用读主机的子expression式 有关从Amazon VPC中恢复互联网的build议 升级到Exchange 2010 安装OpenStack使用devstack安装shell脚本，但得到500错误，当我尝试打开仪表板 XP的VPN客户端DNS问题 在Exchange 2013上安装通讯簿策略代理 在linux中列出具有上次访问date的文件 IBM ServerRAID 6i电池 Subversion提供了错误500，直到通过Web浏览器进行validation Windows Server 2003共享文件权限

AWS ELB延迟问题

我有两个c3.2xlarge的EC2机器在Ubuntu-us-west-2a-AZ。 两者都包含与AWS RDS（db.r3.2xlarge）中的mySQL数据库相同的代码。 这两个实例都被添加到ELB。 两个都有一个计划，一天运行两次。

一旦阈值超过5.0，ELB被configuration为提高警报。 这两个实例的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和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

CPU 利用率 （％）不是关键，关键是CPU 负载平均 （队列）和networking度量，apache度量，缓冲区等。负载平衡器是非常简单的设备，问题，其中LB涉及的架构通常与ELB的，但其余的事情的工作性质。

要查看问题出在哪里，您最需要经过以下步骤：

  • 检查Apache是​​否响应本地请求，如果不是 – 问题不是ELB
  • 检查阿帕奇工人的状态（即mod_status），相应地调整MPM设置
  • 检查CPU负载平均值，如果负载平均增长超过CPU数量和艾奥瓦增长 – 你有IO的麻烦
  • 检查是否启用了连接持久性，如果确实需要连接持久性，如果您真的在需要访问相同Web实例的Web服务器上使用会话
  • 检查apache的存活设置，禁用它或设置非常低的超时值
  • 检查是否在实例上启用了iptables，并且如果nf_conntrack_max和nf_conntrack_count内核参数configuration了更高的值。 如果你不需要它 – closures，不要加载模块
  • 用http请求压力testing单个实例（提示：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的错。