如何排查 Application Load Balancer 的高延迟问题?

上次更新日期:2020 年 10 月 2 日

当我尝试访问在 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" ; done

示例输出:

 | 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 时执行测试。此方法有助于隔离导致延迟的组件。

3.    检查您的 Application Load Balancer 的 Amazon CloudWatch TargetResponseTime 指标的平均统计数据。如果值很高,则后端实例或应用程序依赖性服务器可能存在问题。

4.    通过检查 Application Load Balancer 的访问日志条目确定哪些后端实例遇到高延迟问题。检查 target_processing_time 以查找具有延迟问题的后端实例。此外,请查看 request_processing_timeresponse_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 的利用率,或使用 toppidstat 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。</p


这篇文章对您有帮助吗?


您是否需要账单或技术支持?