並行度配置
工作進程：Worker Process，也稱爲Worker
Config config = new Config();
config.setNumWorkers(3); //注意此參數不能大於supervisor.slots.ports數量。
執行器：Executor，即線程Thread
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout(id, spout, parallelism_hint); //設置Spout的Executor數量參數parallelism_hint
builder.setBolt(id, bolt, parallelism_hint); //設置Bolt的Executor數量參數parallelism_hint
任務：Task
setNumTask() 函數指定每個 executor 的 task 數量
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout(id, spout, parallelism_hint).setNumTasks(val); //設置Spout的Executor數量參數parallelism_hint，Task數量參數val
builder.setBolt(id, bolt, parallelism_hint).setNumTasks(val); //設置Bolt的Executor數量參數parallelism_hint，Task數量參數val
參考：https://www.cnblogs.com/chushiyaoyue/p/6268348.html
拓撲的並行度調整
- 使用Storm的WebUI
- 使用Storm的命令行工具，如下
調整worker並行數：storm rebalance topologyName -n XX
調整topology中某個spout或bolt的並行數：如 storm rebalance topologyName -e boltName=XX
# “myTopology” 拓撲使用5個Worker進程
# “blue-spout” Spout使用3個Executor
# “yellow-blot” Bolt使用10個Executor
storm rebalance myTopology -n 5 -e blue-spout=3 -e yellow-blot=10
注：spout和bolt的並行數，最多可以調整到它的taskNum，默認情況下，taskNum是和你設置的 paralismNum相同的。
設置Bolt或Spout的taskNum
builder.setBolt("cpp", new CppBolt(), 3).setNumTasks(5).noneGrouping(pre_name);
這時提交topology後，默認cpp Bolt的excutor數是3，我們可以通過rebalance -e cpp=5 將其最大調整到5。
參考：https://blog.csdn.net/jmppok/article/details/17243857
Storm UI 解析
首頁
- Supervisors 集羣中配置的 supervisor 數量
- Used slots 集羣中已用掉的 workers 數量
- Free slots 集羣中空閒的 workers 數量
- Total slots 集羣中總的的 workers 數量
- Executors 當前集羣中總的 Executor 線程數量，該值等於集羣中所有 topology 的所有 spout/bolt 配置的 executor 數量之和，其中默認情況下每個 worker 進程還會派生一個 acker executor 線程，也一併計算在內了
- Tasks 當前集羣中總的 task 數量，也是所有 executor 派生的 task 數量之和
- Assigned Mem (MB) 分配給該 topolgoy 下所有 worker 工作內存之和，單個 worker 的內存配置可由 Config.WORKER_HEAP_MEMORY_MB 和 Config.TOPOLOGY_WORKER_MAX_HEAP_SIZE_MB 指定，默認爲 768M，另外再加上默認 64M 的 logwritter 進程內存空間，則有 832M。
- slot 當前節點總的可用 worker 數
- used slot 已用掉的 worker 數
topology 頁面
- Num executors 等於當前 topology 下所有 spout/bolt 的並行度總和，再加上所有 worker 下的 acker executor 線程總數（默認情況下一個 worker 派生一個 acker executor）
- Activate 激活此 topology
- Deactivate 暫停此 topology 運行
- Rebalance 調整並行度並重新平衡資源
- Kill 關閉並刪除此 topology
- Debug 調試此 topology 運行，需要設置 topology.eventlogger.executors 數量 > 0
- Stop Debug 停止調試
- Change Log Level 調整日誌級別
- Window 時間窗口，比如"10m 0s"表示在topology啓動後10m 0s之內
- Emitted 此時間窗口內發射的總tuple數
- Transferred 此時間窗口內成功轉移到下一個bolt的tuple數
- Complete latency (ms) 此時間窗口內每個tuple在tuple tree中完全處理所花費的平均時間
- Acked 此時間窗口內成功處理的tuple數
- Failed 此時間窗口內處理失敗或超時的tuple數
- Id topologoy 中 spout 的名稱，一般是在代碼裏設置的
- Executors 當前分配給此 spout 的 executor 線程總數
- Tasks 當前分配給此 spout 的 task 線程總數
- Emitted 截止當前發射的總tuple數
- Transferred 截止當前成功轉移到下一個bolt的tuple數
- Complete latency (ms) 截止當前每個tuple在tuple tree中完全處理所花費的平均時間
- Acked 截止當前成功處理的tuple數
- Failed 截止當前處理失敗或超時的tuple數
正常情況下 Failed 值爲0，如果不爲0，考慮增加該 spout 的並行度。這是最重要的一個判斷依據；
正常情況下，Emitted、Transferred和Acked這三個值應該是相等或大致相等的，如果相差太遠，要麼該 spout 負載太重，要麼下游負載過重，需要調節該 spout 的並行度，或下游 bolt 的並行度；
Complete latency (ms) 時間，如果很長，十秒以上就已經算很長的了。當然具體時間取決於代碼邏輯，bolt 的結構，機器的性能等。
- Id topologoy 中 bolt 的名稱，一般是在代碼裏設置的
- Executors 當前分配給此 bolt 的 executor 線程總數
- Tasks 當前分配給此 bolt 的 task 線程總數
- Emitted 截止當前發射的總tuple數
- Transferred 截止當前成功轉移到下一個bolt的tuple數
- Complete latency (ms) 截止當前每個tuple在tuple tree中完全處理所花費的平均時間
- Capacity (last 10m) 性能指標，取值越小越好，當接近1的時候，說明負載很嚴重，需要增加並行度，正常是在 0.0x 到 0.1 0.2 左右。該值計算方式爲 (number executed * average execute latency) / measurement time
- Execute latency (ms) 截止當前成功處理的tuple數
- Executed 截止當前處理過的tuple數
- Process latency (ms) 截止當前單個 tuple 的平均處理時間，越小越好，正常也是 0.0x 級別；如果很大，可以考慮增加並行度，但主要以 Capacity 爲準
- Acked 截止當前成功處理的tuple數
- Failed 截止當前處理失敗或超時的tuple數
Capacity (last 10m) 取值越小越好，當接近1的時候，說明負載很嚴重，需要增加並行度，正常是在 0.0x 到 0.1 0.2 左右
Process latency (ms) 單個 tuple 的平均處理時間，越小越好，正常也是 0.0x 級別；如果很大，可以考慮增加並行度，但主要以 Capacity 爲準
如果自己在組件內部採用線程池做一些計算密集型的任務，比如JSON 解析，有可能使得某些組件的資源消耗特別高，其他組件又很低，導致Worker 之間資源消耗不均衡，這種情況在組件並行度比較低的時候更明顯。
比如某個Bolt 設置了1 個並行度，但在Bolt 中又啓動了線程池，這樣導致的一種後果就是，集羣中分配了這個Bolt 的Worker 進程可能會把機器的資源都給消耗光了，影響到其他Topology 在這臺機器上的任務的運行。如果真有計算密集型的任務，我們可以把組件的併發度設大，Worker 的數量也相應提高，讓計算分配到多個節點上。
spout 頁面
注意看，Emitted，Transferred 和 Acked 這幾個參數，看看是否所有的 executor 都均勻地分擔了 tuple 的處理工作。
如果 spout 讀取的是 kafka 的數據，那麼正常情況下，設置爲 topic 的分區數量即可。
kafka 只能保證同一分區下消息的順序性，當 spout 配置了多個 executor 的時候，不同分區的消息會均勻的分發到不同的 executor 上消費，那麼消息的整體順序性就難以保證了，除非將 spout 並行度設爲 1
bolt 頁面
參數同之前頁面，不贅述。
storm調優
1、硬件配置的優化
機器的CPU、帶寬、磁盤性能等也會對 Storm 性能有影響。
2、代碼層面的優化
3、topology 並行度的優化
見Storm UI解析紅字
在設置線程的並行度時，最好能夠根服務器集羣的及其數量和其每臺的cpu的核心數有所關聯。我一般這樣設置，比如，在我的使用的集羣中，假如共有5臺用於工作的服務器，則我在進行資源消耗較多的bolt的並行度設置時，一般設置其並行度是5的倍數，如10,15，20等。這樣可以更容易的促進系統自動進行負載的均衡。
設置好worker的數量。worker是指工作進程的數量，其上可以運行多個工作線程。在設置worker的數量時，首先查看系統中的所有的executors線程數共有多少，比如，有45個。那麼，在設置worker的數量時，最好使得每個worker進程所佔有的線程數不要太大，也不要太小。我一般設置爲3，也就是說每個worker進程大約有3個左右的線程。在上面的45個executors線程的例子中，若共有5臺機器，則設置共有25個worker，則每臺機器上有5個worker；對於45個線程，每臺機器上有15個；這樣一平均，則每個worker進程中有3個executors線程。
4、Storm 集羣配置參數和 topology 運行參數的優化
/** 此參數比較重要，可適當調大一點 */
/** 通常情況下 spout 的發射速度會快於下游的 bolt 的消費速度，當下遊的 bolt 還有 TOPOLOGY_MAX_SPOUT_PENDING 個 tuple 沒有消費完時，spout 會停下來等待，該配置作用於 spout 的每個 task。 */
conf.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, 10000);
/** 設置消息過期時間 秒 */
config.setMessageTimeoutSecs(3600);
/** 調整分配給每個 worker 的內存，關於內存的調節，上文已有描述 */
conf.put(Config.WORKER_HEAP_MEMORY_MB, 768);
conf.put(Config.TOPOLOGY_WORKER_MAX_HEAP_SIZE_MB, 768);
setMaxSpoutPending只對可靠任務起作用，如果不設置MaxSpoutPending 的大小或者設置得太大，可能消耗掉過多的內存導致內存溢出，設置太小則會影響Spout 發射Tuple 的速度。
setMessageTimeoutSecs這個配置設定了一個Tuple數需要應答的最大時間秒數限制，也就是超過這個時間就已經被認爲失敗，可能導致stormUI頁面spout failed 。這個值設置的太小可能會導致tuple反覆重新發送。 默認值爲30s
