# 故事背景

在 Erda 的技術架構中，我們使用了 kong 作為 API 閘道器的技術選型。因其具備高併發低延時的特性，同時結合了 Kubernetes Ingress Controller，基於雲原生的宣告式配置方式，能夠實現豐富的 API 策略。

在我們最早交付的叢集中，kong 還是較為早期的 0.14 版本，隨著業務層面對安全的要求日益趨增，我們需要基於 kong 實現安全外掛，幫助系統能夠具備更好的安全能力。由於較為早期的 0.14 版本不能使用 go-pluginserver 來擴充套件 kong 的外掛機制，我們不得不在古老的叢集中將 kong 升級為相對較新的 2.2.0 版本。

升級過程就不在此贅述了，基本就是照著官方文件一步步順利的升級上去，但是在升級上去之後的幾天裡，我們的 SRE 團隊收到了非常密集的諮詢甚至是聲討，部署在該叢集上的業務**間歇性的無法訪問，延遲非常高**。

# 一系列失敗的嘗試

## 引數調優

最開始為了快速修復這個問題，我們對 kong 的 `NGINX_WORKER_PROCESSES`、`MEM_CACHE_SIZE`、 `DB_UPDATE_FREQUENCY`、`WORKER_STATE_UPDATE_FREQUENCY` 引數以及 postgres 的  `work_mem`、 `share_buffers` 都進行了適當的調優。

但是，沒有任何效果 ?。

## 清理資料

由於這個叢集的歷史原因，會頻繁的註冊或者刪除 api 資料，因此叢集中累計了大約 5 萬多條 route 或者 service 資料。

我們懷疑是資料裡量大導致的效能下降，於是結合 erda 中的資料對 kong 中的歷史資料進行刪除，在刪除的過程中出現的刪除較慢並且同時 kong 的效能急劇下降的現象。

反覆測試了幾次後我們確定了 「**只要呼叫 admin 的介面導致 kong 效能下降**」 這一結論，跟社群的這個問題非常相似，連結如下：

*https://github.com/Kong/kong/issues/7543*

## kong 例項的讀寫分離

確定了是 admin 介面的原因後，我們決定將 admin 跟業務的 kong 例項分開，希望 admin 的呼叫不會影響到業務的正常流量訪問，期待達到 kong 的 admin 介面慢就慢吧，但是不要影響業務的訪問效能。

然而，沒有任何效果?。

## postgres 遷移 RDS

kong 層面的努力無果之後，我們在測試過程中同時觀察到了當呼叫 admin 介面試，postgres 的程式也增多了很多，CPU使用率也漲了起來，也是決定將 pg 遷移到 更為專業的RDS中。

還是，沒有任何效果?。
 
## 回滾

最終我們還是回滾到了 0.14 版本，追求暫時“心靈的寧靜”。

至此，線上的嘗試基本搞一段落，也大致摸清了問題復現的條件，於是我們決定線上下構造一個環境來繼續找出問題的原因。

# 問題的復現之路

我們將出問題的 kong 的 postgres 資料導一份到開發環境中，模擬 「**呼叫 admin 介面是效能急劇下降**」的情況，並尋找解決之道。

## 匯入資料

我們將有問題的叢集中的 postgre 的資料備份之後然後在一個新的叢集中匯入:

```
psql -h 127.0.0.1 -U kong < kong.sql
```

並且開啟 kong 的 prometheus 外掛， 方便使用 grafana 來檢視效能圖示:

```
curl -X POST http://10.97.4.116:8001/plugins --data "name=prometheus"
```

## 現象一

呼叫 admin 服務的 /  同樣的慢，跟線上的現象吻合，當資料量大的時候呼叫 admin 的 / 目錄需要耗費更多的時間。

```
curl http://10.97.4.116:8001
```

![](http://img.blog.itpub.net/blog/2022/07/26/853b56af7cff493e.png?x-oss-process=style/bb)
 
## 現象二

然後我們來模擬線上上遇到的呼叫 admin 介面後業務訪問效能變差的現象，先呼叫 admin 介面建立個業務的 api，以供測試，我們建立了一個 service 以及一個 routes：

```
curl -i -X POST http://10.97.4.116:8001/services/ -d 'name=baidu2'  -d 'url=http://www.baidu.com'

curl -i -X POST http://10.97.4.116:8001/services/baidu2/routes \
-d "name=test2" \
     -d "paths[1]=/baidu2"
```

後面可以使用  `curl http://10.97.4.116:8000/baidu2` 來模擬業務介面進行測試。

準備 admin 介面的測試指令碼， 建立並刪除一個 service/route，中間穿插一個 service list。

```
#!/bin/bash

curl -i -X POST http://10.97.4.116:8001/services/ -d 'name=baidu'  -d 'url=http://www.baidu.com'

curl -i -X POST http://10.97.4.116:8001/services/baidu/routes \
     -d "name=test" \
     -d "paths[1]=/baidu"

curl -s http://10.97.4.116:8001/services

curl -i -X DELETE      http://10.97.4.116:8001/services/baidu/routes/test
```

然後持續呼叫該指令碼：

```
for i in `seq 1 100`; do sh 1.sh ; done
```

在持續呼叫該指令碼的過程中去訪問一個業務的介面，會發現非常慢，跟線上的現象完全吻合。

```
curl  http://10.97.4.116:8000/baidu2
```

![](http://img.blog.itpub.net/blog/2022/07/26/561ae117f825dbc8.png?x-oss-process=style/bb)

PS：精簡指令碼，後只觸發一條寫入，或者刪除也會觸發該現象

## 伴隨現象

- kong 例項的 cpu 跟 mem 都持續上漲，且當 admin 介面呼叫結束後此現象依然沒有結束。mem 上漲到一定程度會到時 nginx worker 程式 oom 掉，然後重啟，這個也許是訪問慢的原因；
- 我們設定了 `KONG_NGINX_WORKER_PROCESSES` 為 4，並且為 pod 的記憶體為 4G 的時候，pod 的整體記憶體會穩定在 2.3G， 但是  呼叫 admin 介面試，pod 的記憶體就會一直上漲至超過 4G，觸發 worker 的 OOM，於是我將 pod 的記憶體調整到了 8G。再次呼叫 admin 介面，發現 pod 的記憶體依然一直上漲，只是上漲到了 4.11 G 就結束了，這似乎意味著我們是要設定 pod  的記憶體為 `KONG_NGINX_WORKER_PROCESSES` 兩倍，這個問題就解決了（但是還有個重要的問題是為什麼呼叫一次 admin 介面，會導致記憶體漲了那麼多）；
- 另外，當我持續呼叫 admin 介面的時候， 最終的記憶體會持續增長並且穩定到 6.9G。

**這個時候我們將問題抽象一下**：

呼叫「kong admin 介面」導致記憶體一直上漲，進而觸發 oom 導致 worker 被 kill 掉，最終導致業務訪問慢。

**繼續調查記憶體是被什麼佔用了**：

我使用 `pmap -x [pid]` 前後兩次檢視了 worker 程式的記憶體分佈，變化的是第二張如中框起來來的部分，從地址上看整塊記憶體都被換過了，但是將記憶體資料匯出並且字串化之後，沒有什麼有效的資訊可供進一步排查。

![](http://img.blog.itpub.net/blog/2022/07/26/f8db85768ee80ee7.png?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/2022/07/26/b3e81b71aa7df197.png?x-oss-process=style/bb)

# 結論

- 該問題跟 kong 的升級（0.14 --> 2.2.0） 沒有關係，直接使用 2.2.0 版本也會有這個問題；
- kong 每隔 `worker_state_update_frequency` 時間後會在記憶體中重建 router，一旦開始重建就會導致 記憶體上漲，看了下程式碼問題出在了 `Router.new` 的方法這裡，會申請 lrucache 但是使用後沒有 flush_all，根據最新的 2.8.1 版本的 lrucache 進行了釋放問題依然存在；
- 也就是 kong 的 `Router.new` 方法裡的其他邏輯到時的記憶體上漲；

![](http://img.blog.itpub.net/blog/2022/07/26/b60cfe55cdc3289b.png?x-oss-process=style/bb)

- 這也就表明這個問題是 kong 存在的一個效能 bug，及時在最新的版本中依然存在，當 route 跟 service 達到某個量級的時候會出現呼叫 admin 介面，導致 kong 的 worker 記憶體迅速上漲，使得 oom 進而引發業務訪問效能變差的現象，臨時的解決辦法可以是減少 `NGINX_WORKER_PROCESSES` 的數量並且增加 kong pod 的記憶體量，保證呼叫 admin 介面後需要的記憶體足夠使用不觸發 oom，才能保證業務的正常使用。

最後，我們會在 *https://github.com/Kong/kong/issues/7543* 這個 issue 中將該現象補充進去，歡迎大家持續關注，一起討論～

----
更多技術乾貨請關注【爾達 Erda】公眾號，與眾多開源愛好者共同成長～

我們被一個 kong 的效能 bug 折騰了一個通宵

相關文章