測試場景
需要使用Jmeter對Go語言實現的后端服務執行階梯遞增式壓測，每階梯增加2000線程，每個階梯維持1小時，直至加壓到10000線程。
每秒發送1次請求，每次請求前需要使用到BeanShell PreProcessor獲取實時時間，生成動態signature，添加到HTTP請求頭中。開啟HTTP請求的keep-alive，設置客戶端實現方式為HttpClient4。
準備1臺8核16G的Linux實例作為控制節點，10臺8核16G的Linux實例作為工作節點（jmeter：5.4.1，jdk：1.8.0_291）
Linux及Jmeter配置優化
1、向/etc/sysctl.conf增加以下內容后，執行sysctl -p /etc/sysctl.conf，優化內核相關參數
????net.ipv4.ip_forward = 1#開啟路由功能
????net.ipv4.conf.default.rp_filter = 1#禁用所有IP源路由
????net.ipv4.conf.default.accept_source_route = 0#禁用icmp源路由選項
????kernel.sysrq = 0#關閉SysRq功能，SysRq代表的是Magic System Request Key
????kernel.core_uses_pid = 1??#控制core文件的文件名是否添加pid作為擴展
????net.ipv4.tcp_syncookies = 1# tcp syncookie，默認關閉
????kernel.msgmnb = 65536 #默認的每個消息隊列的最大尺寸（byte），默認為16384
????kernel.msgmax = 65536#消息隊列中單條消息的最大尺寸（byte),默認8192
????kernel.shmmax = 68719476736#共享內存中的最大內存塊尺寸（byte），默認33554432（32M），這里是65536M
????kernel.shmall = 4294967296??#kernel.shmall的單位是頁面數，當前的x86體系上這個單位是4K,這里是2048G的共享內存總量，默認2097152
????fs.file-max = 6553600??#系統級最大打開文件數，還要結合limits.conf的soft和hard限制
????net.ipv4.tcp_max_tw_buckets = 5000#1st低于此值,TCP沒有內存壓力,2nd進入內存壓力階段,3rdTCP拒絕分配socket(單位：內存頁)
????net.ipv4.tcp_sack = 1#定義SYN重試次數
????net.ipv4.tcp_window_scaling = 1 #開啟窗口縮放功能
????net.ipv4.tcp_rmem = 4096??87380??4194304??#接受緩沖的大小:MIN，DEFAULT,MAX
????net.ipv4.tcp_wmem = 409616384??4194304??#socket的發送緩存區分配的MIN，DEFAULT,MAX
????net.ipv4.tcp_max_syn_backlog = 8192#syn隊列，默認1024，1280可能工作不穩定，需要修改內核源碼參數
????net.core.netdev_max_backlog = 32768#進入包的最大設備隊列.默認是300,對重負載服務器而言,該值太低,可調整到2000.
????net.core.somaxconn = 32768??#listen()的默認參數,掛起請求的最大數量.默認是128.對繁忙的服務器,增加該值有助于網絡性能
????net.core.wmem_default = 8388608#表示套接字發送緩沖區大小的缺省值,會覆蓋net.ipv4.tcp_wmem的DEFAUL值
????net.core.rmem_default = 8388608??#表示套接字接收緩沖區大小的缺省值
????net.core.rmem_max = 16777216??#表示套接字接收緩沖區大小的最大值
????net.core.wmem_max = 16777216??#表示套接字發送緩沖區大小的最大值,會覆蓋net.ipv4.tcp_wmem的MAX值
????net.ipv4.tcp_timestamps = 0??#禁用時間戳，時間戳可以避免序列號的卷繞
????net.ipv4.tcp_synack_retries = 2??#syn-ack握手狀態重試次數，默認5，遭受syn-flood攻擊時改為1或2
????net.ipv4.tcp_syn_retries = 2??#外向syn握手重試次數，默認4
????net.ipv4.tcp_tw_recycle = 1??#開啟 TCP 連接中 TIME-WAIT sockets 的快速回收，默認為 0 ，表示關閉。
????net.ipv4.tcp_tw_reuse = 1#開啟重用。允許將 TIME-WAIT sockets 重新用于新的 TCP 連接，默認為 0 ，表示關閉；
????net.ipv4.tcp_mem = 94500000 915000000 927000000??#1低于此值,TCP沒有內存壓力,2在此值下,進入內存壓力階段，3高于此值,TCP拒絕分配socket.上述內存單位是頁
????net.ipv4.tcp_max_orphans = 3276800 #選項用于設定系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上，如果超過這個數字，孤立連接將立即被復位并打印出警告信息
????net.ipv4.tcp_fin_timeout = 30??#修改系統默認的 TIMEOUT 時間
????net.ipv4.tcp_keepalive_time = 300??#表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為5分鐘。
????net.ipv4.ip_local_port_range = 102465000#表示用于向外連接的端口范圍。缺省情況下過窄：32768到61000，改為1024到65535。
????net.ipv4.ip_conntrack_max = 655360#增大iptables狀態跟蹤表
????net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180#設置默認 TCP 連接時長為180秒
2、向/etc/security/limits.conf增加以下內容
*soft nofile 65535
*hard nofile 65535
再向/etc/profile增加以下內容，執行source /etc/profile，持久優化文件句柄
ulimit -n 65535
4、jmeter.properties配置設置
httpclient.reset_state_on_thread_group_iteration=false #線程組每次循環是否重置連接狀態
client.tries=3 #初始化遠程工作節點重試次數
client.retries_delay=3000 #初始化遠程工作節點超時時間
httpclient4.retrycount=1 #請求重試次數
httpclient4.idletimeout=60000 #連接空閑時間
httpclient4.time_to_live=60000 #連接保持時間
5、bin/jmeter文件，JVM優化
: "${HEAP:="-Xms12g -Xmx12g -Xss512k -XX:MaxMetaspaceSize=1g"}"
: "${GC_ALGO:="-XX:+UseG1GC -XX:+DisableExplicitGC -XX:MaxGCPauseMillis=100 -XX:G1ReservePercent=20 -XX:+UseStringDeduplication -XX:ConcGCThreads=2"}"
問題現象
遠程調用執行，持續40分鐘以后，設置的12GB堆空間不足，jmeter發送的請求量大幅下降。
使用ps -ef|grep java|awk '{printf $2}'|head -1|xargs -I {} jstat -gc {} 2000，查看JVM的GC狀態。可查看到大量老年代資源累積，最終觸發FullGC，而后不斷頻繁觸發FullGC。
排查問題
1、使用jmap -dump:live,format=b,file=heapLive.hprof ${jmeter_pid}命令，獲取堆快照文件
2、將文件下載到本地后，執行jvisualvm命令，打開jvisualvm，并加載堆快照文件，分析堆空間使用信息
通過分析堆快照，我們可以看到，堆空間的使用，主要被bsh類下的實例及String類型使用。
通過堆快照分析，我們定位出了Jmeter的性能問題主要出現在Beanshell生成signature給http請求使用這塊。首先，我們先禁用掉BeanShell PreProcessor組件，直接以每臺1000線程（共計10000線程）的并發量運行，看內存溢出問題是否消失，來驗證我們的猜想。
禁用掉BeanShell PreProcessor組件后，以每臺1000線程（共計10000線程）的并發量運行，最終看到，工作節點的內存最終維持到了8GB左右，并可持續運行40min以上，證明了我們的猜想是正確的。
所以我這邊，首先是對BeanShell中的代碼進行了優化，使用StringBuilder拼接字符串，將signature生成并put后，設置所有new出的對象為null。啟用BeanShell PreProcessor組件，而后再次以每臺1000線程（共計10000線程）的并發量運行，工作節點最終仍然出現了內存溢出的問題，說明存在內存溢出的地方可能并不是beanshell的代碼。
4、網上查閱資料，最終確定是Jmeter的BeanShell組件存在內存溢出的問題，官方文檔的說明如下：
在長時間運行的Jmeter腳本中，使用BeanShell組件，會占用大量內存；如果需要長時間運行，則需要設置BeanShell組件中reset Interpreter選項為True。
但是通過設置BeanShell組件中reset Interpreter選項為True，我們再次運行Jmeter測試，會發現雖然內存增加的問題得到了較大的改善，但測試的吞吐量無法達到期望效果，這顯然也是我無法接受的。
通過jstack -F ${jmeter_pid}命令，發現大量的線程處于阻塞狀態，通過閱讀Jmeter源碼發現解釋器重置，每次都需要重新執行java.lang.ClassLoader.loadClass方法，該方法存在一個synchronized同步塊阻塞了線程，從而導致吞吐率無法提高。
問題解決
由于BeanShell組件存在內存溢出的問題，且在設置reset Interpreter選項為True后，吞吐量會被限制，我不得不選擇放棄使用BeanShell來實現生成signature的功能。
目前可供我使用的方案有兩種：
1、使用官方支持的Groovy或Jexl3等開發腳本來實現（通過查詢網上資料，了解到Groovy雖然內存占用在合理范圍內，但和BeanShell存在相同的類加載引發的線程阻塞問題，導致吞吐率很低）
2、使用Jmeter自定義函數（我目前使用的是這一種方式，經測試能有效的避免內存溢出問題，并且不會存在線程阻塞導致吞吐量不達標的問題）
關于如何實現Jmeter自定義函數，詳見文章：http://www.lxweimin.com/p/37f1e8329fc7
