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

簡短描述

Application Load Balancer 造成高延遲的可能原因包括：

• 網路連線問題
• 後端執行個體的記憶體 (RAM) 使用率過高
• 後端執行個體的 CPU 使用率過高
• 後端執行個體上的 Web 伺服器組態不正確
• 在後端執行個體上執行的 Web 應用程式相依性問題，例如外部資料庫或 Amazon Simple Storage Service (Amazon S3) 儲存貯體

解決方法

1.    使用對 Application Load Balancer 進行疑難排解中的疑難排解步驟來檢查網路連線問題。

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 服務或 Proxy 伺服器。

9.    使用下列 Linux 工具來識別伺服器上的效能瓶頸。

uptime – 顯示負載平均值，以協助確定等待執行的任務 (處理程序) 數量。在 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。

---