mysqlslap --iterations=100 --create-schema=『test『 --query="query.sql" --number-of-queries=20000 --delimiter=";" --concurrency=100
3.2.2 網路引數問題
問題描述
使用mysqlslap 壓測某個語句，當併發數提公升到200或400時，cdb效能下降，不符合業務預期。
排查過程
這裡只和高併發有關，cdb團隊首先想到的是mysql是否開啟了thread pool功能，對於cdb和自建均未開啟thread pool功能，而在cdb上開啟了thread pool功能後問題仍然存在。而且在本地和遠端壓測都存在同樣問題，這也排除了網路的因素。
有乙個細節是cdb團隊觀察到壓測過程中資料庫的連線數並不穩定，忽上忽下，就開始懷疑是mysqlslap壓測工具的問題。於是cdb團隊開始檢視mysqlslap原始碼, 確認mysqlslap用的是否是短連線。然而mysqlslap用的是長連線，並不是短連線。但有一種情況，當mysqlslap執行完一輪(number_of_querys)語句後會新建連線。當壓測引數iterations設定較大，number_of_querys較小，並且調大併發數時，每個連線執行的語句相對就少了。也就是說，當併發數增大時，壓測過程中的新建連線增加了。為了驗證這個問題， cdb團隊調大壓測引數number_of_querys後，壓測效能就上去了。
到這裡，問題可以歸結為大量建立連線影響了效能。於是cdb團隊開始查詢tcp相關系統引數的區別，通過修改主機引數tcp_rmem/tcp_wmem/tcp_max_syn_backlog/somaxconn，解決了高併發下的效能下降問題。
問題原因
mysqlslap的實現方式是每次迭代都後重新建立連線，即所有客戶端執行完number_of_queries數量的sql後會重新建連連線，當併發增加時，每個客戶端執行的sql相對較少，mysqlslap這種長連線測試方式退化類似於短連線的測試方式，而cdb主機對短連線處理的不是特別好。解決方案
修改主機引數， 提高了建立連線效率
tcp_rmem="4096 873800 4194304" (原"4096 87380 4194304"， tcp receive memory buffers)
tcp_wmem = "4096 163840 4194304" (原"4096 16384 4194304"， tcp send memory buffers)
tcp_max_syn_backlog=3240000 (原4096, sync queue size)
somaxconn = 2048(原128， accept queue size)
方案效果
mysql 效能壓測後調優 MySQL效能測試調優
mysql效能測試調優 作業系統 基本操作 檢視磁碟分割槽mount選項 mount 永久修改分割槽mount選項 系統重啟後生效 修改檔案 etc fstab 中對應分割槽的mount options列的值 sudo t ext4 o remount,noatime,errors remount ...
mysql集群 儲存過程 mysql集群壓測
mysql壓測 mysql自帶就有乙個叫mysqlslap的壓力測試工具，通過模擬多個併發客戶端訪問mysql來執行壓力測試，並且能很好的對比多個儲存引擎在相同環境下的併發壓力效能差別。通過mysqlslap help可以獲得可用的選項，這裡列一些主要的引數，更詳細的說明參考官方手冊。如果是系統自帶...
python連線mysql並提交mysql事務示例
複製 如下 coding utf 8 import sys import mysqldb reload sys sys.setdefaultencoding utf 8 class db object def init self,host 127.0.0.1 port 3306,user root ...