共計 2952 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關如何實現 RocketMQ 性能壓測分析，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

一   機器部署 1.1  機器組成

1 臺 nameserver

1 臺 broker  異步刷盤

2 臺 producer

2 臺 consumer

1.2  硬件配置

CPU  兩顆 x86_64cpu, 每顆 cpu12 核，共 24 核

內存  48G

網卡   千兆網卡

磁盤   除 broker 機器的磁盤是 RAID10，共 1.1T，其他都是普通磁盤約 500G

1.3  部署結構

橙色箭頭為數據流向，黑色連接線為網絡連接

1.4  內核參數

broker 是一個存儲型的系統，針對磁盤讀寫有自己的刷盤策略，大量使用文件內存映射，文件句柄和內存消耗量都比較巨大。因此，系統的默認設置并不能使 RocketMQ 發揮很好的性能，需要對系統的 pagecache，內存分配，I/ O 調度，文件句柄限制做一些針對性的參數設置。

系統 I / O 和虛擬內存設置

echo  vm.overcommit_memory=1    /etc/sysctl.conf

echo  vm.min_free_kbytes=5000000    /etc/sysctl.conf

echo  vm.drop_caches=1    /etc/sysctl.conf

echo  vm.zone_reclaim_mode=0    /etc/sysctl.conf

echo  vm.max_map_count=655360    /etc/sysctl.conf

echo  vm.dirty_background_ratio=50    /etc/sysctl.conf

echo  vm.dirty_ratio=50    /etc/sysctl.conf

echo  vm.page-cluster=3    /etc/sysctl.conf

echo  vm.dirty_writeback_centisecs=360000    /etc/sysctl.conf

echo  vm.swappiness=10    /etc/sysctl.conf

系統文件句柄設置

echo  ulimit -n 1000000    /etc/profile

echo  admin hard nofile 1000000    /etc/security/limits.conf

系統 I / O 調度算法

deadline

1.5 JVM 參數

采用 RocketMQ 默認設置

 -server -Xms4g -Xmx4g -Xmn2g -XX:PermSize=128m -XX:MaxPermSize=320m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+CMSClassUnloadingEnabled -XX:SurvivorRatio=8 -XX:+DisableExplicitGC -verbose:gc -Xloggc:/root/rocketmq_gc.log -XX:+PrintGCDetails -XX:-OmitStackTraceInFastThrow 

二   性能評測 2.1  評測目的

壓測單機 TPS，評估單機容量

2.2  評測指標

最高的 TPS 不代表最適合的 TPS，必須在 TPS 和系統資源各項指標之間取得一個權衡，系統資源快達到極限，但尚能正常運轉，此時的 TPS 是比較合適的。比如 ioutil 最好不要超過 75%,cpu load 最好不超過總的核數或者太多，沒有發生頻繁的 swap 導致較大的內存顛簸。所以不能只關注 TPS，同時要關注以下指標：

消息：TPS

cpu：load,sy,us

內存：useed,free,swap,cache,buffer

I/O：iops,ioutil, 吞吐量 (數據物理讀寫大小 / 秒)

網絡：網卡流量

2.3  評測方式

兩臺 producer 起等量線程，不間斷的向 broker 發送大小為 2K 的消息，2K 消息意味著 1000 個字符，這個消息算比較大了，完全可以滿足業務需要。

2.4  評測結果

TPS 比較高

  經過長時間測試和觀察，單個 borker TPS 高達 16000，也就是說服務器能每秒處理 16000 條消息，且消費端及時消費，從服務器存儲消息到消費端消費完該消息平均時延約為 1.3 秒，且該時延不會隨著 TPS 變大而變大，是個比較穩定的值。

Broker 穩定性較高

  兩臺 producer 一共啟動 44 個線程 10 個小時不停發消息，broker 非常穩定，這可簡單意味著實際生產環境中可以有幾十個 producer 向單臺 broker 高頻次發送消息，但是 broker 還會保持穩定。在這樣比較大的壓力下，broker 的 load 最高才到 3（24 核的 cpu），有大量的內存可用。

  而且，連續 10 幾小時測試中，broker 的 jvm 非常平穩，沒有發生一次 fullgc，新生代 GC 回收效率非常高，內存沒有任何壓力，以下是摘自 gclog 的數據：

2014-07-17T22:43:07.407+0800: 79696.377: [GC2014-07-17T22:43:07.407+0800: 79696.377: [ParNew: 1696113K- 18686K(1887488K), 0.1508800 secs] 2120430K- 443004K(3984640K), 0.1513730 secs] [Times: user=1.36 sys=0.00, real=0.16 secs] 

新生代大小為 2g，回收前內存占用約為 1.7g，回收后內存占用 17M 左右，回收效率非常高。

  關于磁盤 IO 和內存

  平均單個物理 IO 耗時約為 0.06 毫秒，IO 幾乎沒有額外等待，因為 await 和 svctm 基本相等。整個測試過程，沒有發生磁盤物理讀，因為文件映射的關系，大量的 cached 內存將文件內容都緩存了，內存還有非常大的可用空間。

系統的性能瓶頸

  TPS 到達 16000 后，再就上不去了，此時千兆網卡的每秒流量約為 100M，基本達到極限了，所以網卡是性能瓶頸。不過，系統的 IOUTIL 最高已經到達 40% 左右了，這個數字已經不低了，所以即使網絡流量增加，但是系統 IO 指標可能已經不健康了，總體來看，單機 16000 的 TPS 是比較安全的值。

以下是各項指標的趨勢

TPS

TPS 最高可以壓倒 16000 左右，再往上壓，TPS 有下降趨勢

內存
內存非常平穩，總量 48G，實際可用內存非常高
沒有發生 swap 交換，不會因為頻繁訪問磁盤導致系統性能顛簸
大量內存被用來作為文件緩存，見 cached 指標，極大的避免了磁盤物理讀

磁盤吞吐量

隨著線程數增加，磁盤物理 IO 每秒數據讀寫大約為 70M 左右

IO 百分比

隨著線程數增加，IO 百分比最后穩定在 40% 左右，這個數字可以接受

關于“如何實現 RocketMQ 性能壓測分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。