訂閱端每隔500ms呼叫一次amqp_consume_message介面函式從socket上獲取資料，正常情況下，伺服器每次會推送幾百條訊息，而且推送的頻率會比較高；
導致訂閱端的本機socket緩衝區會很快存滿，導致很多訊息無法進行快取，而被丟掉；
發布訊息條數
呼叫amqp_comsume_message間隔(ms)
實際接收條數
630500
269695
470269
513460
269503
450503
訊息包大小由1k到10mb，當包大小達到4.5mb時，伺服器的效能出現明顯的異常，傳輸率尤其是每秒訂閱訊息的數量，出現波動，不穩定；同時有一部分訂閱者的tcp連線出現斷開的現象。可能是客戶端底層或者rabbitmq服務端在進行拆包，組包的時候，出現了明顯的壓力，而導致異常的發生。具體可參見官方部落格
磁碟也可能形成瓶頸，如果單台機器佇列很多，確認只在必要時才使用duration(持久化)，避免把磁碟跑滿；
佇列的訊息大量累積後，傳送和消費速度都會受到影響，導致服務進一步惡化，採用的方法是，額外的指令碼監控每個佇列的訊息數，超過限額會執行purge操作，簡單粗暴但是有效的保證了服務穩定；
由於用執行緒模擬大量發布者，且是伺服器單節點，受客戶端主機網絡卡的限制，發布執行緒沒有速度控制，導致有大量資料傳送，伺服器頻寬下行速率也滿負荷，上行頻寬卻明顯低於下行速率，導致伺服器記憶體有大量訊息堆積，進而觸發rabbitmq伺服器paging操作，才出現了上述不穩定和訂閱者斷開現象。
對發布端做適當流量控制，斷開連線現象不再出現，但每秒訊息數仍然不穩定
分析三種模式directfanouttopic
不同的模式對於新建交換機、新建佇列、繫結等操作效能影響不大，
但是在direct模式下明顯訊息發布的效能比其他模式強很多，並且訊息傳送到相同佇列比傳送到不同佇列效能稍好
在訊息持久化模式下：
發布：13888msg/s
訂閱：15384msg/s
發布：18867msg/s
訂閱：26315msg/s
可以看到rabbitmq的記憶體 占用占用已經使用了7.8g允許的值為.6g左右
因為vm_memory_high_watermark值設定的是0.4也就是物理記憶體的40%；伺服器為16g * 40% = 6.4g
一般在產生的原因是長期的生產者傳送速率大於消費者消費速率導致. 觸發了rabbitmq 的流控；
解決方案：
增加消費者端的消費能力,或者增加消費者(根本解決)
控制訊息產生者端的傳送速率(不太現實)
增加mq的記憶體(治標不治本)
vm_memory_high_watermark：用於配置記憶體閾值，建議小於0.5，因為erlang gc在最壞情況下會消耗一倍的記憶體。
vm_memory_high_watermark_paging_ratio：用於配置paging閾值，該值為1時，直接觸發記憶體滿閾值，block生產者。
io_thread_pool_size：cpu大於或等於16核時，將erlang非同步執行緒池數目設為100左右，提高檔案io效能。
hipe_compile：開啟erlang hipe編譯選項（相當於erlang的jit技術），能夠提高效能20%-50%。在erlang r17後hipe已經相當穩定，rabbitmq官方也建議開啟此選項。
queue_index_embed_msgs_below：rabbitmq 3.5版本引入了將小訊息直接存入佇列索引（queue_index）的優化，訊息持久化直接在amqqueue程序中處理，不再通過msg_store程序。由於訊息在5個內部佇列中是有序的，所以不再需要額外的位置索引(msg_store_index)。該優化提高了系統效能10%左右。
queue_index_max_journal_entries：journal檔案是queue_index為避免過多磁碟定址新增的一層緩衝（記憶體檔案）。對於生產消費正常的情況，訊息生產和消費的記錄在journal檔案中一致，則不用再儲存；對於無消費者情況，該檔案增加了一次多餘的io操作。
沒測
RabbitMq 效能調優記錄
訂閱端每隔500ms呼叫一次amqp consume message介面函式從socket上獲取資料，正常情況下，伺服器每次會推送幾百條訊息，而且推送的頻率會比較高 導致訂閱端的本機socket緩衝區會很快存滿，導致很多訊息無法進行快取，而被丟掉 發布訊息條數 呼叫amqp comsume mess...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...