WebService CPU 用量高

[chinghongfang]

在測試比較 topic collector 和 local collector 時，發現 WebService 啟動後 CPU 用量很高 (和使用 StrictCostPartitioner 的 performance tool 相當)

環境

執行軟體	B1	B2	B3	B4	B5	B6
Controller	V
Kakfa Broker	V	V	V	V	V	V
Node Exporter	V	V	V	V	V	V
Prometheus	V
Grafana	V

執行軟體	C1	C2	C3	C4	C5	C6	C7	C8	C9
Node Exporter	V	V	V	V	V	V	V	V	V
Performance tool	V	V	V	V	V	V	V	V	V

這次的測試會把 WebService 和 performance tool 分開時間啟動，方便釐清問題。 另外，為了公平比較， WebService 改到 client 的機器啟動，在同一個機器下觀察 WebService 和 performance tool 的 CPU 使用率。

步驟

1. 首先建立一個 9000 partition 的 topic (before 14:26)
2. C1 啟動 WebService (local metric collect) (14:26:15)
3. 刪除 topic (with 9000 partitions) (14:30:30)
4. C1 停止 WebService (14:34:30)
5. 建立一個 9000 partition 的 topic (14:30:00)
6. C1~C9 啟動 performance tool (local metric collect) (14:37:00)

指令

C1 建立 WebService

WEB_PORT=8001 REVISION=c9a00b3e70942d7c606cc3f01c87815a609fc155 /home/kafka/astraea/docker/start_app.sh web --bootstrap.servers 192.168.103.185:9092 --jmx.port 8000 --port 8001

C1 ~ C9 執行 performance tool

REVISION=c9a00b3e70942d7c606cc3f01c87815a609fc155 /home/kafka/astraea/docker/start_app.sh performance --bootstrap.servers 192.168.103.185:9092 --value.size 10KiB --value.distribution fixed --run.until 10m --producers 4 --consumers 0 --topics large --partitioner org.astraea.common.partitioner.StrictCostPartitioner --configs jmx.port=8000

結果

WebService 啟動時的 CPU 用量落在 10.2% ~ 24.7% 在第 3. 步驟的時候 (刪除 topic)， CPU 用量有下降許多 (變成 1.1% ~ 1.8%)，可以說明 partition 多的時候 metric 收集負擔大。 後面 performance tool 使用的 StrictCostPartitioner 也使用相同的 metric 收集方法， CPU 用量落在 12.0% ~ 32.4%

[chinghongfang]

由刪除 9000 partition 的 topic 的動作，可以看出 WebService CPU 負擔高是因為 partition 數量多 (-> metric 多 -> local collector 忙)，而這是合理的現象，也正是 topic collector 想要解決的問題。

因為已經知道 WebService CPU 負載的來源，且有 topic collector 解決此一問題，所以關閉此一議題。