rabbitmq 故障記錄

2022-07-06 01:54:09 字數 1866 閱讀 3978

update memory details  顯示其other 為3.8g

rabbitmqctl status 檢視記憶體

在broker執行過程中修改:rabbitmqctl set_vm_memory_high_watermark 0.6

查詢修改是否成功:

已恢復可以使用,但是erlang processes 分布異常需進一步跟進處理,erlang記憶體分析方法:  

other部分記憶體釋放,

重啟後過一段時間開發同學報rabbitmq 週期性連線失敗問題,

重啟此ram節點導致新的問題出現,最好將此節點從集群中剔除,

# 集群剔除節點

# 在要剔除的節點上執行

rabbitmqctl stop

# 在其餘倆節點分別執行

rabbitmqctl forget_cluster_node rabbit@node1

# 將節點加入集群

# 在要加入的節點上執行

rabbitmqctl reset

rabbitmqctl join_cluster rabbit@rabbitpro01-fn --ram

rabbitmq 將每個佇列設計為乙個 erlang 程序,erlang 程序gc也是採用分代策略,當新老生代一起參與major gc時,erlang虛擬機會新開記憶體,根據root set將存活的物件拷貝至新空間,這個過程會造成新老記憶體空間同時存在,極端情況下,乙個佇列可能短期內需要兩倍的記憶體佔用量,所以記憶體流控閥值設定為0.4相對是乙個比較安全的值,設定太高,有可能系統記憶體被全部占用導致系統程序 kill rabbitmq程序,設定過低導致記憶體使用率不高。

因為rabbitmq伺服器在啟動時會計算系統記憶體總大小。然後會根據vm_memory_high_watermark引數指定的百分比,進行控制.可通過命令 rabbitmqctl set_vm_memory_high_watermark fraction 動態設定。預設下,vm_memory_high_watermark的值為0.4,當rabbitmq使用的記憶體超過40%時,系統會阻塞所有連線。一旦警報解除(訊息被消費者取走,或者訊息被寫到硬碟中),系統重新恢復工作。32位系統的單程序記憶體使用最大為2g,即使系統有10g,那麼記憶體警報線為2g*40%.

由於某一訊息佇列 訊息積壓(1.5億條訊息)導致 磁碟空間使用率100%(三個節點都打滿)

通過web介面qeues->purge刪除訊息導致介面卡死,最終使用命令列刪除 :rabbitmqctl purge_queue qeueuname

刪除過程比較耗時,需等待一段時間,最終刪除成功,三個節點的磁碟使用率降下來

RabbitMQ使用記錄

公司業務比較複雜,各部門使用的技術也不一樣,往往在業務互動處理處是乙個頭疼問題,為了方便使用,於是搭建了這個mq。至於為什麼使用這個mq,這裡不做解說,我們在支付訂單業務上通過mq保證各系統連貫正常,這裡收集了相關資料,方便大家使用。安裝 訪問控制 網路 配置 集群 命令 前台執行 rabbitmq...

rabbitmq 命令記錄

1.檢視所有佇列 sh rabbitmqctl list queues 2.檢視所有消費者 sh rabbitmqctl list consumers 查詢某個佇列的消費者 sh rabbitmqctl list consumers grep notify center t1 to d0 real ...

RabbitMQ機制記錄

1 topic模式機制測試結果 1 客戶端連線不同佇列,當exchange發布訊息通過routing key到不同佇列時,兩個佇列均能收到訊息。2 exclusive,設定為true時,客戶端連線斷掉,佇列消失,且佇列內資料丟失。2 延遲執行 主要靠外掛程式 rabbitmq plugins ena...