如何實現RocketMQ性能壓測分析

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

一   機器部署

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性能壓測分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。