一 機器部署

1.1 機器組成

1臺nameserver

1臺broker 異步刷盤

2臺producer

1.2 硬件配置

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

內存 48G

網卡 千兆網卡

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

系統文件句柄設置 對IO讀寫要求高的系統

echo ‘ulimit -n 1000000‘ >> /etc/profile

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

系統I/O調度算法

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 評測目的

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是比較安全的值。

隨著線程數增加，最後穩定在3左右，對於總共24核的兩顆CPU，這點load根本不算什麽

磁盤吞吐量

RocketMQ性能壓測分析（轉載）