MySQL数据库压测有哪些注意事项和FAQ-创新互联
下面讲讲关于MySQL数据库压测有哪些注意事项和FAQ，文字的奥妙在于贴近主题相关。所以，闲话就不谈了，我们直接看下文吧，相信看完MySQL数据库压测有哪些注意事项和FAQ这篇文章你一定会有所受益。
1.注意事项
（1）.提前规划好具体要测试什么，即测试目的，比如
MySQL5.6与5.7的性能差异；
异步复制和半同步复制的TPS；
设置双1（innodb_flush_log_at_trx_commit=1、sync_binlog=1）性能对数据库性能影响多少；
确认即将上线的新业务对MySQL负载影响多少，是否能承载得住，是否需要对云服务器进行扩容或升级配置；
(2).压力测试比较耗时，我们不可能时刻监督每次压测什么时候结束，然后手动的进行下一次测试，所以要写个脚本帮助我们一键测试；
(3).根据测试环境的硬件配置给予机器适当的压力，对于有限的硬件配置，不能无限的增压，这样数据库里全是lock wait timeout等报错，最后会使MySQL Crash的。
2.FAQ
这一块主要讲测试的时候系统和数据库出现的问题，导致压测无法进行
(1)tpcc数据库在预热rampup时候的报错
sht-sgmhadoopcm-01:mysqladmin:/usr/local/mysql/tpcc-mysql-master/logs:>less tpcc_runlog_parameter_20180620234749_512_THREADS RAMP-UP TIME.(120 sec.) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382) 1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382)解决方法：
错误很明显，参数max_prepared_stmt_count(默认16382)现在的大小已经无法满足负载需求了，这个参数是限制数据库中已经准备的statements数量，即sql数量，我们把它增大十倍。
sht-sgmhadoopdn-02.telenav.cn:mysqladmin:/usr/local/mysql/data:>vim /ect/my.cnf
max_prepared_stmt_count = 163820
然后重启MySQL
mysql> show variables like '%max_prepared_stmt_count%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| max_prepared_stmt_count = | 163820 |
+-------------------------+-------+
参数官方解析：
This variable limits the total number of prepared statements in the server. It can be used in environments where there is the potential for denial-of-service attacks based on running the server out of memory by preparing huge numbers of statements. If the value is set lower than the current number of prepared statements, existing statements are not affected and can be used, but no new statements can be prepared until the current number drops below the limit. The default value is 16,382. The permissible range of values is from 0 to 1 million. Setting the value to 0 disables prepared statements.
(2)MySQL负载过高，导致crash
数据库日志也出现大量的日志信息：
sht-sgmhadoopdn-02.telenav.cn:mysqladmin:/usr/local/mysql/data:>vim sht-sgmhadoopdn-01.err 2018-06-20T17:04:42.935422Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5690ms. The settings might not be optimal. (flushed=1119 and evicted=0, during the time.) 2018-06-20T17:05:45.061790Z 0 [ERROR] Error in accept: Too many open files 2018-06-20T17:05:47.846070Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5057ms. The settings might not be optimal. (flushed=912 and evicted=0, during the time.) 2018-06-20T17:06:09.564302Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4569ms. The settings might not be optimal. (flushed=913 and evicted=0, during the time.) 2018-06-20T17:06:35.456128Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5822ms. The settings might not be optimal. (flushed=959 and evicted=0, during the time.) 2018-06-20T17:06:47.324711Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4312ms. The settings might not be optimal. (flushed=673 and evicted=0, during the time.) 2018-06-20T17:06:55.651725Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5018ms. The settings might not be optimal. (flushed=592 and evicted=0, during the time.) 2018-06-20T17:07:09.104978Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4983ms. The settings might not be optimal. (flushed=936 and evicted=0, during the time.) 2018-06-20T17:07:21.873005Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4723ms. The settings might not be optimal. (flushed=677 and evicted=0, during the time.) 2018-06-20T17:07:40.903065Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4432ms. The settings might not be optimal. (flushed=431 and evicted=0, during the time.) 2018-06-20T17:08:13.283422Z 1085 [ERROR] Can't generate a unique log-filename /usr/local/mysql/arch/mysql-bin.(1-999) 2018-06-20T17:08:13.283501Z 1085 [ERROR] mysqld: Binary logging not possible. Message: Either disk is full or file system is read only while rotating the binlog. Aborting the server. 17:08:13 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=268435456 read_buffer_size=2097152 max_used_connections=981 max_threads=214 thread_count=981 connection_count=981 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1272281 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f55ddfa9710 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7f55bac30ea8 thread_stack 0x40000 mysqld(my_print_stacktrace+0x35)[0xf4a495] mysqld(handle_fatal_signal+0x4a4)[0x7ce2f4] /lib64/libpthread.so.0(+0xf5e0)[0x7f5774a0b5e0] /lib64/libc.so.6(gsignal+0x37)[0x7f57733fd1f7] /lib64/libc.so.6(abort+0x148)[0x7f57733fe8e8] mysqld[0xee249a] mysqld(_ZN13MYSQL_BIN_LOG13new_file_implEbP28Format_description_log_event+0x50c)[0xeeec4c] mysqld(_ZN13MYSQL_BIN_LOG6rotateEbPb+0x3e)[0xeeed0e] mysqld(_ZN13MYSQL_BIN_LOG14ordered_commitEP3THDbb+0x497)[0xef1137] mysqld(_ZN13MYSQL_BIN_LOG6commitEP3THDb+0x585)[0xef1825] mysqld(_Z15ha_commit_transP3THDbb+0x174)[0x81f594] mysqld(_Z12trans_commitP3THD+0x49)[0xdd1589] mysqld(_Z21mysql_execute_commandP3THDb+0x2be0)[0xd186d0] mysqld(_Z11mysql_parseP3THDP12Parser_state+0x40d)[0xd1af7d] mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x119a)[0xd1c19a] mysqld(_Z10do_commandP3THD+0x194)[0xd1d044] mysqld(handle_connection+0x29c)[0xded7ac] mysqld(pfs_spawn_thread+0x174)[0xf707b4] /lib64/libpthread.so.0(+0x7e25)[0x7f5774a03e25] /lib64/libc.so.6(clone+0x6d)[0x7f57734c034d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7f55de4918b0): is an invalid pointer Connection ID (thread ID): 1085 Status: NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.解决方法：
建议：不要给与数据库太大的压力，控制好thread并发数
(3)linux某一用户达到max user processes后，导致暂时无法使用该用户mysqladmin登录和无法使用任何bash命令
-bash-4.2$ sudo su mysqladmin
su: failed to execute /bin/bash: Resource temporarily unavailable
sht-sgmhadoopcm-01:mysqladmin:/usr/local/mysql/tpcc-mysql-master/logs:>ls
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
解决方法：
查看系统的一些限制设置，发现max user processes 只有4096，进程被用完，所以无论写入什么命令，系统都无法及时作出响应
[root@sht-sgmhadoopcm-01 ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31207
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@sht-sgmhadoopcm-01 ~]# vim /etc/security/limits.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
还需要修改一个默认的配置文件才能真正的生效：
[root@sht-sgmhadoopcm-01 ~]# vim /etc/security/limits.d/20-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 65536 #把这里的4096改大为65536或者为unlimited
root soft nproc unlimited
查看已经生效：
sht-sgmhadoopcm-01:mysqladmin:/usr/local/mysql/tpcc-mysql-master/logs:>ulimit -u
65536
（4）并发太大，导致大量的lock
当线程数达到1536及以上的时候，日志中出现大量的lock信息：
$less tpcc_runlog_parameter_20180621170023_1536_THREADS payment 1466:1 payment 247:1 1205, HY000, Lock wait timeout exceeded; try restarting transaction 1205, HY000, Lock wait timeout exceeded; try restarting transaction payment 954:1 1205, HY000, Lock wait timeout exceeded; try restarting transaction payment 485:1 1205, HY000, Lock wait timeout exceeded; try restarting transaction payment 266:1 1205, HY000, Lock wait timeout exceeded; try restarting transaction ...... ....... 2013, HY000, Lost connection to MySQL server at 'reading initial communication packet', system error: 104 2013, HY000, Lost connection to MySQL server at 'reading initial communication packet', system error: 104 2013, HY000, Lost connection to MySQL server at 'reading initial communication packet', system error: 104 2013, HY000, Lost connection to MySQL server at 'reading initial communication packet', system error: 104 2013, HY000, Lost connection to MySQL server at 'reading initial communication packet', system error: 104解决方法：
此时查看MySQL中的一些Lock状态信息,可以看出来全部都是一些x锁，说明现在并发过大，导致数据库处理不过来，产生大量排它锁。
mysql> select * from INFORMATION_SCHEMA.INNODB_LOCKS; +------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data | +------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | 15043927:63:3:8 | 15043927 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043750:63:3:8 | 15043750 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043742:63:3:8 | 15043742 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043700:63:3:8 | 15043700 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043656:63:3:8 | 15043656 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043646:63:3:8 | 15043646 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043607:63:3:8 | 15043607 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043399:63:3:8 | 15043399 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | | 15043388:63:3:8 | 15043388 | X | RECORD | `tpccdb`.`warehouse` | PRIMARY | 63 | 3 | 8 | 7 | ...... | 15043727:64:3:56 | 15043727 | X | RECORD | `tpccdb`.`district` | PRIMARY | 64 | 3 | 56 | 6, 5 | | 15035687:64:3:62 | 15035687 | X | RECORD | `tpccdb`.`district` | PRIMARY | 64 | 3 | 62 | 7, 1 | | 15043855:64:3:62 | 15043855 | X | RECORD | `tpccdb`.`district` | PRIMARY | 64 | 3 | 62 | 7, 1 | | 15032784:64:3:56 | 15032784 | X | RECORD | `tpccdb`.`district` | PRIMARY | 64 | 3 | 56 | 6, 5 | +------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ 1756 rows in set, 1 warning (3.87 sec)建议：不要给与数据库太大的压力，控制好thread并发数
(5)由于磁盘空间不足，导致OS和MySQL相关报错
在启动MySQL的时候err日志报的错误：
TPCC压测时候的日志报错
sht-sgmhadoopcm-01:mysqladmin:/usr/local/mysql/tpcc-mysql-master/logs:>less tpcc_runlog_parameter_20180625075957_1024_THREADS
delivery 241:5
1114, HY000, The table 'order_line' is full
delivery 823:5
1114, HY000, The table 'order_line' is full
delivery 618:5
......
......
使用vim打开一个文件的时候报错
E297: Write error in swap file
"hostname.err" [noeol] 3437L, 417792C
Press ENTER or type command to continu
解决方法：
sht-sgmhadoopdn-01.telenav.cn:mysqladmin:/usr/local/mysql/data:>df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/centos-root xfs 77G 77G 12M 100% /
devtmpfs devtmpfs 2.9G 0 2.9G 0% /dev
tmpfs tmpfs 2.9G 0 2.9G 0% /dev/shm
tmpfs tmpfs 2.9G 65M 2.8G 3% /run
tmpfs tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup
/dev/sda1 xfs 497M 132M 366M 27% /boot
建议：删除无用的文件释放disk space,或者mount一个更大的磁盘
对于以上MySQL数据库压测有哪些注意事项和FAQ相关内容，大家还有什么不明白的地方吗？或者想要了解更多相关，可以继续关注我们的行业资讯板块。
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
标题名称：MySQL数据库压测有哪些注意事项和FAQ-创新互联
网址分享：https://www.cdcxhl.com/article44/ecpee.html
成都网站建设公司_创新互联，为您提供移动网站建设、虚拟主机、网站收录、定制网站、静态网站、网站维护
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联
- 手机端网站制作设计按照这个原则来做是最完美的 2016-10-31
- 手机建站需求注意的误区有哪些 2015-07-26
- 建设移动手机网站的注意事项 2016-10-24
- 手机网站的优势和重要性 2016-09-14
- 制作手机网站需要注意哪些必要因素？ 2013-10-28
- 嘉定手机网站建设已成企业建站趋势 2020-11-24
- 手机网站建设选哪家最好？ 2019-01-10
- 手机网站建设有哪些优势? 2016-11-02
- 手机网站建设有助于企业与时俱进吗？ 2016-10-29
- 手机网站建设需要注意什么 2022-06-27
- 手机app开发有什么商业价值 2015-12-26
- 重庆手机网站建设做SEO有哪些优势 2021-01-16