壓測中踩過的幾個坑（等待測試數據獲取完成...）
###############################
1.thread到達100以上之后出現報錯：
1205, HY000, Lock wait timeout exceeded; try restarting transaction
該報錯一度讓我以為找到了性能的極限....
然而查看系統資源，cpu和內存使用率不到10%
------------
對于該報錯，度娘出的結果大概有2種
①增大innodb_log_buffer_size
然而我把size從8M擴到了8G都沒有卵用....
②增大innodb_lock_wait_timeout
我首先檢查了autocommit參數，確認該參數值為1
然后把innodb_lock_wait_timeout值由50增加到500（默認單位為秒）
問題基本解決
（順便查詢了一下這個參數，默認值50秒，該參數的意義是50秒后還不能獲取到這個鎖，就認為是一個死鎖，回滾事務）
個人粗略理解：所以增大該值，也就是多等一會，直到獲取該鎖，執行事務
2.動態修改參數后未修改/data/mysql/mysql3306/my3306.cnf中參數的值
由于每次測試之后，需要執行MySQL的重啟，而個人習慣一直是指定defaults-file來啟動，因此動態修改innodb_buffer_pool_size值為4G在重啟后完全失效，因此此次測試4G組的數據無效
此外前面動態修改的全局變量innodb_lock_wait_timeout=500，該值并沒有寫到my3306.cnf里，重啟之后發現系統里面又變成了默認值50
然后就導致大量的lock wait timeout提示，然我一度以為這個參數對于256的thread無能為力
3.建倉太小，導致free buffer一直沒能消耗完
參照葉總發的標準，此次tpcc壓測的建倉數為20，當innodb_buffer_pool_size調整到6G之后，經歷了相當一段時間的壓測，在庫里執行
show engine innodb status \G可以發現free buffer還沒到0
強度不達標的壓測是沒有意義的~
4.高并發值下的報錯：Can't create more than max_prepared_stmt_count statements (current value: 16382)
tpcc測試在并發數達到400以后開始出現這個報錯，而sysbench在并發數為500時仍然可以正常測試；
該報錯涉及到MySQL的一個參數：max_prepared_stmt_count
該值默認為16382，范圍在0 - 1048576之間
將其修改為124000之后繼續測試
參數與結果
###############################
在本篇開頭提到一個1205的報錯，根據網文的建議，我把innodb_log_file_size從100M提升到了8G，當時我正在進行innodb_buffer_pool_size從100M提升到2G的測試，Tpmc值從300躍升到21000+的巨大變化讓我以為這一切都是buffer_pool_size的功勞，然而在后來的一次測試中，4G的Tpmc值竟然只有15000+，百撕不得騎姐了很久...??
后來因為要做log_buffer的測試，加上測試久了log變得很大，對參數調整時把log_file_size減小到800M，在對buffer_pool_size=2G的測試中發現Tpmc竟然只有3000+，4G的Tpmc也只有5000+，這才讓我意識到log_file_size這個“看似不起眼”的參數對性能也是有相當的影響的...
###############################
1.innodb_buffer_pool_size
毫無疑問對結果影響最重大的一個參數，該值越大，對應的TpmC值越大；
在專用于DB的服務器上，該值設置成總內存的75%比較合適
如果系統有Swap分區，該值設置超過物理內存時（超出部分占用Swap）也會獲得更高的TpmC值。（通常來說DB服務器不會設置Swap）
2.innodb_log_file_size
本次測試涉及的4個參數中，該參數的大小同樣可以左右TpmC值；
測試了該參數為0.1G，1G，2G，4G，8G時的TpmC值，測試表明TpmC值隨著該參數的不斷增大而增大，但該參數到達4G以后，TpmC值的增長趨于平緩，因此在TPCC的測試中，該值設置為4G較為合適。
該參數對應著ib_logfile的值
在TPCC測試結束后，采用sysbench又進行了一次測試，在該次測試中，log_file=1G時的TPS值與log_file=4G或者8G時的TPS幾乎一致，將該參數調整至100M后，TPS才出現了較大的變化。 很明顯的該值并非和前面的buffer_pool_size一樣是越大越好，而是應該參考數據庫平時log的寫入實際情況來進行設置
3.innodb_log_buffer_size
在本次測試中，該參數采用了8M，16M，64M，128M等4個值，測試中該參數的取值對于TpmC的影響并不明顯，總體來講該參數取16M時的TpmC值最為理想
4.Threads
在TPCC的測試中，由于之前的max_stmt報錯，導致最大并發數只增加到300便沒有繼續增大進行測試，因此在TPCC模式的測試中，并發數對于最后結果的影響不算太明顯。
在后續進行的sysbench測試中，并發數取值范圍從2-1000
當并發數為2時，TPS值相對較低，隨著并發數上升到30以上，TPS能夠保持相對正常的水平，后續隨著并發數的不斷增加，TPS雖然仍然保持在正常水平，但響應時間也隨之增加，單純對TPS進行解讀已經失去了意義。
對數據進行觀察可以發現，當并發數位于30-100階段時，綜合TPS和響應時間等因素，系統性能最佳。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?參數持續增加中，待續....
