昨天使用gdb調(diào)試MySQL中事務(wù)臨界狀態(tài)的時候，發(fā)現(xiàn)其實有些場景可能比我想得還要復(fù)雜一些，所以我在昨天的測試中結(jié)尾也是快快掃過，但是表明了意思即可。這一點上我在后面會把Oracle的臨界事務(wù)狀態(tài)也拿出來對比一下，還是蠻有意思的。
創(chuàng)新互聯(lián)建站專注于東湖網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供東湖營銷型網(wǎng)站建設(shè)，東湖網(wǎng)站制作、東湖網(wǎng)頁設(shè)計、東湖網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造東湖網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供東湖網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
今天簡單寫了幾個腳本繼續(xù)對一個測試環(huán)境的MySQL進行sysbench壓力測試。
先突破1000連接資源設(shè)置的瓶頸在上一次的基礎(chǔ)上，我們保證了能夠滿足短時間內(nèi)1000個連接的沖擊，從各個方面做了調(diào)整，其中的一個重點逐漸落到了IO的吞吐率上，redo日志的大小設(shè)置一下子成了焦點和重中之重。
當(dāng)然這次的測試中，我的思路還是保持性能持續(xù)的增長，邊調(diào)整，邊優(yōu)化。
首先一點是我們能夠突破1000連接的大關(guān)，先用下面的腳本來進行一個初步的測試，測試時長10秒鐘，看看能否初始化1500個連接。
sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3306 --mysql-socket=/home/mysql/s1/s1.sock --mysql-host=localhost --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=1500 --report-interval=5 --time=10 run沒想到就跟約好似的，拋出了如下的錯誤。注意這里的錯誤看起來已經(jīng)不是數(shù)據(jù)庫層面了。
FATAL: unable to connect to MySQL server on socket '/home/mysql/s1/s1.sock', aborting...
FATAL: error 2001: Can't create UNIX socket (24)
PANIC: unprotected error in call to Lua API (cannot open
/home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open
files)
PANIC: unprotected error in call to Lua API (cannot open
/home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open
files)是不是支持的socket數(shù)的限制呢，我們已經(jīng)調(diào)整了process的值。上面的命令我們可以換個姿勢來寫，那就是從socket連接改為常用的TCP/IP方式的連接.
sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=perf_test --mysql-port=3306 --mysql-host=10.127.128.78 --mysql-password=perf_test --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=1500 --report-interval=5 --time=10 run可以看到錯誤就顯示不同了，但是已經(jīng)能夠看出意思來了。
FATAL: unable to connect to MySQL server on host '10.127.128.78', port 3306, aborting...
FATAL: error 2004: Can't create TCP/IP socket (24)
PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files)
PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files)對此應(yīng)很明確了，那就是內(nèi)核資源設(shè)置nofile調(diào)整一下。
修改/etc/security/limits.d/90-nproc.conf文件，添加如下的部分即可，重新登錄后即可生效。
* soft nproc 65535
* soft nofile 65535
* hard nofile 65535
重啟MySQL后可以看到設(shè)置生效了。# cat /proc/`pidof mysqld`/limits | egrep "(processes|files)"
Max processes 65535 256589 processes
Max open files 65535 65535 files
我們繼續(xù)開啟壓測模式，馬上錯誤就變了樣。是我們熟悉的一個錯誤，最開始就碰到了。
FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:273: SQL API error
(last message repeated 1 times)
FATAL: mysql_stmt_prepare() failed
FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 100000)"
FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:273: SQL API error
這里得簡單說說幾個相關(guān)的額參數(shù)。
Com_stmt_close prepare語句關(guān)閉的次數(shù)
Com_stmt_execute prepare語句執(zhí)行的次數(shù)
Com_stmt_prepare prepare語句創(chuàng)建的次數(shù)這一類的場景可能不是通用的，因為在有些場景下，持續(xù)的連接，不是短時間內(nèi)的大批量連接，這個參數(shù)max_prepared_stmt_count其實也不一定需要設(shè)置非常大。
比如我手頭一個環(huán)境連接數(shù)有近500，但是max_prepared_stmt_count還是默認(rèn)值16382，也穩(wěn)定運行了很長時間了。# mysqladmin pro|wc -l
424
# mysqladmin var|grep max_prepared_stmt_count
| max_prepared_stmt_count | 16382
我們的這個壓測場景中，會短時間內(nèi)創(chuàng)建大量的連接，而考慮到性能和安全，會使用prepare的方式，我們以10秒內(nèi)的sysbench連接測試威力，看看prepare statement的數(shù)量變化。
使用show global status like '%stmt%'能夠得到一個基本的數(shù)據(jù)變化。
mysql> show global status like '%stmt%';
+----------------------------+--------+
| Variable_name | Value |
+----------------------------+--------+
| Com_stmt_execute | 477403 |
| Com_stmt_close | 91000 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 298844 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
| Com_stmt_reprepare | 0 |
| Prepared_stmt_count | 0 |
+----------------------------+--------+過幾秒查看，可以看到Prepared_stmt_count已經(jīng)接近閾值。
mysql> show global status like '%stmt%';
+----------------------------+--------+
| Variable_name | Value |
+----------------------------+--------+
| Binlog_stmt_cache_disk_use | 0 |
| Binlog_stmt_cache_use | 0 |
| Com_stmt_execute | 477403 |
| Com_stmt_close | 91000 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 398045 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
| Com_stmt_reprepare | 0 |
| Prepared_stmt_count | 98091 |
+----------------------------+--------+
按照目前的一個基本情況，我們需要 設(shè)置為91*1500=136500，留有一定的富余，所以我們可以設(shè)置為150000
然后繼續(xù)測試，就會看到這個參數(shù)逐步的飛升。
mysql> show global status like '%stmt%';
+----------------------------+--------+
| Variable_name | Value |
+----------------------------+--------+
| Binlog_stmt_cache_disk_use | 0 |
| Binlog_stmt_cache_use | 0 |
| Com_stmt_execute | 624184 |
| Com_stmt_close | 91000 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 537982 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
| Com_stmt_reprepare | 0 |
| Prepared_stmt_count | 136500 |
+----------------------------+--------+整個加壓的過程中，可以通過top看到負(fù)載還是有一定的潛力,離性能榨干還有距離。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13417 mysql 20 0 34.8g 11g 12m S 1324.2 35.2 19:18.71 /usr/local/mysql/bin/mysqld --defaults-file=/home
23108 root 20 0 8924m 1.6g 2148 S 212.3 5.0 1:32.73 sysbench /home/sysbench/sysbench-1.0.3/src/lua/olt
下面的圖是我使用100M,200M,500,1G的redo得到的TPS圖。
通過這個圖也能過看出一個基本的負(fù)載情況，在1G的時候，TPS相對比較平穩(wěn)，但是redo切換還是多多少少都會有一定的抖動。當(dāng)然redo不是越大越好，
5.5 中的設(shè)置是小于 4G， 5.6 以后是小于512G
我們持續(xù)進行優(yōu)化。
重慶分公司
重慶分公司
