如何解讀分銷商的存儲和控制隊列中的消息數量？

Question

本文講述控制隊列N sb個主節點用來控制消息的負載，但對我來說仍不清楚如何解釋的郵件數的比例失調在這個隊列：https://docs.particular.net/nservicebus/msmq/distributor/

我觀察緩慢在我的N sb個服務之前從未經歷過緩慢。出於某種原因，與每個主節點相比，每個主節點都會創建較少的並行線程，並且工作人員或主節點配置中沒有任何更改，如分配的最大線程數量。我試圖弄清楚它是不是想爲工人提供飼料的主節點，還是工人不想承擔更多工作。

我看到控制隊列中的消息數量從15跳到40，而存儲只有5-8。我應該將此解釋爲準備工作的員工，而分銷商無法向他們發送更多消息？謝謝

Answer 1

只要分發者正在發送消息，控制和storage queue中的數字就會上下跳動。進入control queue的消息將立即從隊列中彈出並顯示在storage queue上。進入分銷商的primary queue的消息將立即導致storage queue的第一條消息被彈出。 很難解釋正在運行的分發服務器的隊列中的消息數量，因爲在您使用計算機管理或隊列資源管理器查看數字時，它們將發生更改。

極端情況是這樣的：

1.在經銷商的主要輸入隊列和沒有工作發生任何工人的任何消息。

• 輸入隊列：0
• 控制隊列：0
• 存儲隊列：工人的數量*每名工人

2.所有工人都在滿負荷工作配置線程。沒有人能夠承擔更多的工作。

• 輸入隊列：0+（成長，如新郵件拉斯維加斯）
• 控制隊列：0
• 存儲隊列：0

在正在運行的系統，它可以是任何之間這兩個極端，所以，不幸的是，僅僅從control和storage queue的快照中很難說很多。

一些故障排除提示：

• 如果storage queue是空的，經銷商不能把手伸到更多的工作。它不知道在哪裏發送它。如果所有工作人員都完全佔用，則會發生這種情況，因爲他們不會將任何就緒消息發送回control queue，直到他們完成處理消息。

• 如果storage queue與所有員工中的工作線程總數相比一直較小，那麼您即將接近工人的總最大容量。

• 我建議你開始看看工人的日誌，看看他們正在做的工作是否比平時花費的時間更長。較慢的數據庫/第三方集成？

• 另一件要檢查的是，是否有任何IO重量被添加到託管分銷商的機器上。如果分銷商已經在接近最大容量的情況下運行，增加額外的IO可能會降低MSMQ的速度，從而導致吞吐量下降。