如何對 Elastic Load Balancing 中 Application Load Balancer 的高延遲問題進行疑難排解？

簡短描述

以下是導致 Application Load Balancer 高延遲的原因：

• 網路連線或擁塞問題
• 後端執行個體的記憶體 (RAM) 使用率偏高
• 後端執行個體 CPU 使用率偏高
• 後端執行個體上的 Web 伺服器組態不正確
• 在後端執行個體上執行的 Web 應用程式相依性出現問題
• 用戶端或內部部署目標目標與 Application Load Balancer 之間的地理距離較遠

解決方法

若要對 Application Load Balancer 的高延遲問題進行疑難排解，請執行以下動作：

• 檢查網路連線問題。如需詳細資訊，請參閱 Application Load Balancer 疑難排解。

• 測量第一個位元組回應，並檢查可能導致延遲的慢速 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
  ===============

  **注意：**若要隔離導致延遲的原因，請使用 Application Load Balancer 完成上述步驟，然後再次完成該步驟並繞過 Application Load Balancer 。如需詳細資訊，請參閱 curl 網站上的 curl 手冊頁面。

• 檢查 Application Load Balancer 在 Amazon CloudWatch 中 TargetResponseTime 指標的平均統計資料。如果該值很高，則表示後端執行個體或應用程式相依伺服器存在問題。如需更多資訊，請參閱如何對 Application Load Balancer TargetResponseTime 指標增加的問題進行疑難排解？

• 若要識別具有高延遲的後端執行個體，請檢查 Application Load Balancer 的存取日誌項目。

• 若要識別具有延遲問題的後端執行個體，請檢查 target_processing_time 是否超出正常時間段。

• 若要確認 Application Load Balancer 是否有問題，請檢查 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，而 respond_processing_time 為 0.001。target_processing_time 值顯示的時間比正常時間要長，且 Application Load Balancer 目標導致了延遲。如需詳細資訊，請參閱語法。

• 若要識別高 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

• 若要檢查您的執行個體可以同時處理多少個請求，請查看後端執行個體上網路伺服器的 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 發行版，您可能需要手動安裝一些上述命令。