Rabbitmq內存控制，隊列已滿並且不是分頁。連接掛起

Question

我正在測試rabbitMQ，芹菜設置。

在當前的設置中有一個jobqueue（2GB RAM，65GB HD），只有一個工作人員將大量消息推送到隊列中（稍後我們將添加一堆工作人員）。當jobqueue達到大約1100萬條消息時，連接掛起（很確定這是blocking由於基於內存的流量控制，如http://www.rabbitmq.com/memory.html）。但連接永遠掛起，永遠不會關閉連接，也不會分頁到磁盤。這是不受歡迎的行爲 - 導致芹菜工人變成殭屍過程。

在考慮系統可能實際需要的總大小時 - 我們希望隊列能夠承載10000次這樣的負載 - 總共最多約300億條消息在隊列中一次。

下面是一些相關設置：

{vm_memory_high_watermark,0.8}, 
{vm_memory_high_watermark_paging_ratio,0.5}] 

最初，我們改變了vm_high_watermark從1.4至2.8，這使得在隊列中更多的消息，但仍然不夠。

我們正在考慮當然系統在某些時候需要更多的RAM，雖然在這之前我們想了解當前的問題以及如何處理它。

現在，隊列中只有11m任務，它使用2GB RAM的80％，整個系統只使用8GB的磁盤。考慮到我們將vm_memory_high_watermark設置爲.8，內存使用情況很有意義。儘管如此，磁盤使用對我來說毫無意義 - 並且表明分頁沒有發生。爲什麼不讓RabbitMQ分頁到磁盤以便讓隊列增長更多？雖然明顯放慢了隊列機器的運行速度，但這樣可以避免死機 - 並且看起來像是理想的回退行爲。 AFAIK這確實是整個分頁的重點。

其他說明：

我們確認，連接吊，從那時起已在事實上被封鎖41小時（通過檢查rabbitmqctl report的連接部分）。根據http://www.rabbitmq.com/memory.html這意味着「流量控制正在發生」。問題是 - 爲什麼不是將消息分頁到磁盤？

其他詳情：

的Ubuntu 12.04.3 LTS

的RabbitMQ 3.2.2，二郎R14B04

芹菜3.0.24

的Python 2.7.3

Answer 1

如果您的隊列不耐用，沒有消息將被分頁到磁盤。系統將受可用內存的限制。如果您需要將消息刷新到磁盤，請使用durable=true隊列。

而這種設計，有很多的負載，而不是消費信息，是不理想的。 RabbitMQ不是數據庫，這些消息是暫時的。如果您需要數據存儲，請使用Redis，RDBMS等。