如何解决弹性负载均衡中应用程序负载均衡器的高延迟问题？

简短描述

以下是应用程序负载均衡器高延迟的原因：

• 网络连接或拥塞问题
• 后端实例的内存 (RAM) 使用率高
• 后端实例上的 CPU 使用率高
• 后端实例上的 Web 服务器配置不正确
• 在后端实例上运行的 Web 应用程序依赖项存在问题
• 客户端或本地目标与应用程序负载均衡器之间的地理距离很大

解决方法

要解决应用程序负载均衡器上的高延迟问题，请执行以下操作：

• 检查是否存在网络连接问题。有关详细信息，请参阅 Troubleshoot your Application Load Balancers。

• 测量第一个字节响应并检查 DNS 解析速度是否较慢，这可能会导致延迟：

  curl -kso /dev/null -w "\n===============\n
  | DNS lookup: %{time_namelookup}\n
  | Connect: %{time_connect}\n
  | App connect: %{time_appconnect}\n
  | Pre-transfer: %{time_pretransfer}\n
  | Start transfer: %{time_starttransfer}\n
  | Total: %{time_total}\n
  | HTTP Code: %{http_code}\n===============\n" https://example.com/

  输出示例：

  ===============
  | DNS lookup: 0.002346
  | Connect: 0.003080
  | App connect: 0.008422
  | Pre-transfer: 0.008587
  | Start transfer: 0.050238
  | Total: 0.057486
  | HTTP Code: 200
  ===============

  **注意：**要找出导致延迟的原因，请使用您的应用程序负载均衡器完成前面的步骤，然后再次完成该步骤并绕过应用程序负载均衡器。有关详细信息，请参阅 curl 网站上的 curl man page。

• 查看您的应用程序负载均衡器的亚马逊 CloudWatch ** TargetResponseTime ** 指标的平均统计数据。如果值很高，则说明您在后端实例或应用程序依赖项服务器上出现了问题。有关详细信息，请参阅如何对应用程序负载均衡器的 TargetResponseTime 指标增加进行故障排除？

• 要识别高延迟的后端实例，请检查应用程序负载均衡器的访问日志条目。

• 要识别存在延迟问题的后端实例，请检查 target_processing_time 是否存在异常长的时间段。

• 要确认应用程序负载均衡器中的问题，请查看 request_processing_time 和 response_processing_time 字段，了解是否存在异常长的时间段。

  日志条目示例：

  http 2024-04-01T22:23:00.765170Z app/example-loadbalancer/50dc6c495c0c9188
  192.168.131.39:2817 10.0.0.1:80 0.001 12.401 0.001 200 200 34 366
  "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
  arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067
  "Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
  0 2024-04-01T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"

  **注意：**前面的日志条目示例显示 request_processing_time 为 0.001，target_processing_time 为 12.401， response_processing_time 为 0.001。target_processing_time 值显示异常长的时间段，并且应用程序负载均衡器目标导致延迟。有关详细信息，请参阅语法。

• 要确定高的 CPU 利用率或 CPU 利用率的峰值，请检查您的后端实例的 CloudWatch CPUUtilization 指标。要解决高 CPU 利用率，请将您的实例升级到更大的实例类型。

• 要查看后端的 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

• 要查看您的实例可同时处理的请求数量，请查看您的后端实例上 Web 服务器的 MaxClient 设置。如果您的实例具有适当的内存和 CPU 利用率并且仍然存在高延迟，请提高 MaxClient 值。

• 将 Apache 生成的进程数量 (httpd) 与 MaxClient 值进行比较。如果 Apache 进程的数量经常达到 MaxClient 值，请增加 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>

检查后端依赖项

检查可能导致延迟问题的后端实例上的依赖项。依赖项示例包括 Amazon Simple Storage Service (Amazon S3) 存储桶、网络地址转换 (NAT) 实例或代理服务器以及远程 Web 服务。

使用 Linux 工具识别性能瓶颈

要确定服务器上的性能瓶颈，请使用以下 Linux 命令：

• 运行 uptime 命令以检查由于资源争用而导致的系统负载平均值是否过高。输出显示系统负载平均值，即等待运行或在 I/O 上被阻塞的任务数。
• mpstat -P ALL 1 命令向您显示了每个内核的 CPU 使用率明细。运行该命令以确定不平衡的使用情况，例如在单线程应用程序中由单核处理大部分工作。
• 要识别一段时间内占用大量资源的进程和模式，请运行 pidstat 1 命令。输出显示了按进程划分的实时 CPU 使用情况。
• 运行 dmesg | tail 命令以识别最近可能影响性能的系统级事件。输出显示最近 10 条系统消息。
• 要识别高读取或写入操作或缓慢的磁盘性能，请运行 iostat -xz 1 命令。输出显示磁盘 I/O 指标和使用情况。
• 运行 free -m 命令查看可用的系统内存。如果可用内存不足，则系统可能依赖交换来增加磁盘 I/O 和延迟。
• 要确定带宽饱和度，请运行 sar -n DEV 1 tool 命令。输出显示网络接口吞吐量，包括接收 (rxkB/s) 和传送 (txkB/s) 流量。
• 运行 sar -n TCP,ETCP 1 以查看以下可帮助您确定连接问题的关键 TCP 指标：
  active/s 指标是每秒本地启动的 TCP 连接的数量。
  passive/s 指标是每秒远程启动的 TCP 连接的数量。
  retrans/s 指标是每秒 TCP 重新传输次数。当此指标较高时，您可能会遇到数据包丢失或拥塞的情况。
• 要确定哪些在网络上使用最多的带宽，请运行 iftop 命令。输出实时显示每个连接的活动带宽使用情况。
• niftop 命令是 iftop 的一个变体，可以通过 Red Hat Enterprise Linux (RHEL) 和基于 Debian 的发行版上的第三方存储库获得。如果您的系统上没有预装 iftop，请使用 niftop。

**注意：**根据您的 Linux 发行版，您可能需要手动安装前面的一些命令。