原創文章，轉載請注明出處：http://jameswxx.iteye.com/blog/2093785
一 機器部署
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
系統文件句柄設置
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根本不算什么
內存非常平穩，總量48G，實際可用內存非常高
沒有發生swap交換，不會因為頻繁訪問磁盤導致系統性能顛簸
大量內存被用來作為文件緩存，見cached指標，極大的避免了磁盤物理讀
磁盤吞吐量
隨着線程數增加，磁盤IOPS大約穩定在5000左右
注意非常重要的細節，即使在高達16000TPS時，磁盤仍然沒有發生物理讀，這和內存的cached指標是遙相呼應的，文件幾乎全部在內存里，沒有發生一次物理讀，所以文件讀的效率非常高，消息消費非常快
