只有经过测试，才知道参数的设置对系统性能的影响有多大！

压测中踩过的几个坑（等待测试数据获取完成...）

###############################

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

（并不是需要一定是0,1000左右已经算是基本耗尽buffer了）

强度不达标的压测是没有意义的~

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和响应时间等因素，系统性能最佳。

                                                                                                                                                                             参数持续增加中，待续....