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

简短描述

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。

---