如何排查 Application Load Balancer 的高延迟问题?
当我尝试访问在 Application Load Balancer 后注册的目标上运行的 Web 应用程序时,遇到高延迟和超时问题。我应该如何解决这些问题?
简短描述
Application Load Balancer 上出现高延迟的可能原因包括:
- 网络连接问题
- 后端实例上的高内存 (RAM) 利用率
- 后端实例上的高 CPU 利用率
- 后端实例上的 Web 服务器配置不正确
- 在后端实例上运行的 Web 应用程序依赖性问题,例如外部数据库或 Amazon Simple Storage Service (Amazon S3) 存储桶
解决方法
1. 按照排查 Application Load Balancers 问题中的故障排查步骤检查网络连接问题。
2. 使用 curl 工具测量第一个字节响应,并检查 DNS 解析缓慢是否是造成延迟的原因。
curl -kso /dev/null https://www.example.com -w "==============\n\n | dnslookup: %{time_namelookup}\n | connect: %{time_connect}\n | appconnect: %{time_appconnect}\n | pretransfer: %{time_pretransfer}\n | starttransfer: %{time_starttransfer}\n | total: %{time_total}\n | size: %{size_download}\n | HTTPCode=%{http_code}\n\n"
示例输出:
| dnslookup: 0.005330 | connect: 0.006682 | appconnect: 0.026540 | pretransfer: 0.026636 | starttransfer: 0.076980 | total: 0.077111 | size: 12130 | HTTPCode=200
通过 Application Load Balancer 执行这些测试。然后,在绕过至目标的 Application Load Balancer 时执行测试。此方法有助于隔离导致延迟的组件。有关 curl 功能的更多信息,请参阅如何使用 curl 功能。
3. 检查您的 Application Load Balancer 的 Amazon CloudWatch TargetResponseTime 指标的平均统计数据。如果值很高,则后端实例或应用程序依赖性服务器可能存在问题。
4. 通过检查 Application Load Balancer 的访问日志条目确定哪些后端实例遇到高延迟问题。检查 target_processing_time 以查找具有延迟问题的后端实例。此外,请查看 request_processing_time 和response_processing_time 字段,以验证 Application Load Balancer 是否出现任何问题。
5. 针对您的后端实例查看 CloudWatch CPUUtilization 指标。查找高 CPU 利用率或 CPU 利用率的峰值。要获得较高的 CPU 利用率,请考虑将实例升级为更大的实例类型。
6. 通过查看后端实例上的 Apache 进程来检查内存问题。
示例命令:
watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"
示例输出:
Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no- headers | wc -1 && free –m Apache Processes: 27 total used free shared buffers cached Mem: 8204 7445 758 0 385 4567 -/+ buffers/cache: 2402 5801 Swap: 16383 189 16194
7. 检查您的后端实例上的 Web 服务器的 MaxClient 设置。此设置定义了实例可以同时处理的请求数量。对于适当的内存和 CPU 利用率遇到高延迟的实例,请考虑增加 MaxClient 值。
比较 Apache (httpd) 生成的进程数与 MaxClient 设置。如果 Apache 进程的数量经常达到 MaxClient 值,请考虑增加该值。
[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15
<IfModule prefork.c> StartServers 10 MinSpareServers 5 MaxSpareServers 10 ServerLimit 15 MaxClients 15 MaxRequestsPerChild 4000 </IfModule>
8. 检查可能导致延迟问题的后端实例的依赖性。依赖关系可能包括共享数据库或外部资源(例如 Amazon S3 存储桶)。依赖关系还可能包括外部资源连接,例如网络地址转换 (NAT) 实例、远程 Web 服务或代理服务器。
9. 使用以下 Linux 工具来确定服务器上的性能瓶颈。
正常运行时间 – 显示负载平均值,以帮助确定等待运行的任务(进程)数。在 Linux 系统上,此数字包括等待在 CPU 上运行的进程,以及在不间断 I/O(通常是磁盘 I/O)中被阻止的进程。此数据提供必须使用其他工具解释的资源负载(或需求)的高级视图。当 Linux 负载平均值增加时,对资源的需求也会增加。要确定哪些资源需求较高,您必须使用其他指标。例如,对于 CPU,您可以使用 mpstat -P ALL 1 来测量每个 CPU 的利用率,或使用 top 或 pidstat 1 来测量每个进程的 CPU 利用率。
mpstat -P ALL 1 – 显示每个 CPU 的 CPU 细分时间,您可以用它来检查不平衡性。单个热 CPU 或许是某个单线程应用程序的证据。
pidstat 1 – 显示每个进程的 CPU 利用率并打印滚动摘要,这对于长期观察模式非常有用。
dmesg | tail – 显示最后 10 条系统消息(如果有)。查找可能导致性能问题的错误。
iostat -xz 1 – 显示应用于数据块设备(磁盘)的工作负载及产生的性能。
free -m – 显示可用内存量。检查并确认这些数字的大小不接近零,这可能会导致磁盘 I/O 提高(使用 iostat 确认),性能下降。
sar -n DEV 1 – 将网络接口吞吐量(rxkB/s 和 txkB/s)显示为工作负载的衡量指标。检查是否已达到任何限制。
sar -n TCP,ETCP 1 – 显示关键 TCP 指标,包括:active/s(每秒钟在本地启动的 TCP 连接数)、passive/s(每秒钟远程启动的 TCP 连接数)和 retrans/s(每秒钟的 TCP 重新传输次数)。
iftop – 显示服务器与使用带宽最多的远程 IP 地址之间的连接。n iftop 提供在一个软件包中,该软件包在基于 Red Hat 和 Debian 的发行版中具有相同的名称。但是,在基于 Red Hat 的发行版中,您可能会在第三方存储库中找到 n iftop。

相关内容
- 已提问 4 个月前lg...
- 已提问 4 个月前lg...
- 已提问 5 个月前lg...
- 已提问 5 个月前lg...
- 已提问 2 个月前lg...
- AWS 官方已更新 9 个月前
- AWS 官方已更新 4 年前
- AWS 官方已更新 3 个月前
- AWS 官方已更新 8 个月前