|
Review the MySQL/InnoDB improvement history. You can easily find out. In MySQL 5.6 stable release, read-only speedup has never been so fast, it is easy to understand, and has good scalability in read-only (RO). Also looking forward to it reaching a higher level on read+write (RW). (Especially when reading data is the main job of the database) However. We are also very happy with the performance of RO in MySQL 5.6. In version 5.7, the main work is concentrated on read+write (RW), because the processing of big data has not yet met our expectations. But RW relies on RO. Ability to increase speed again. The InnoDB team has made strong efforts to optimize the performance per second of version 5.7 through continuous improvement. The following will explain to you in order |
you want paws
|
|
In fact, read-only workloads control internal linking in MySQL in two ways:
The workload of any fast single-table range test is mostly locked due to MDL linking. And multiple tables will be limited due to InnoDB internals (different tables will be protected by different MDL locks, so the link bottleneck in MDL will be lower in this case). But again, it also depends on the size of the workload - a measure of more read-only work than normal will perform better in MySQL 5.6 (eg Sysbench OLTP_RO), while less workload and faster queries (eg Sysbench Point-Selects (to fetch a record with a foreign key)) will make all the links difficult and can only be measured in 16-core-HT, and 32-core is poor.. but anything like Point-Select The workload of the test will be to work with all MySQL internals that will allow you to see the maximum performance possible (start with SQL parser, terminate with row values).. at your given MySQL version and given HW When configured, this may also reach the maximum SQL queries per second (QPS) rate. |
Translated by yale8848
|
|
The best result we got on Mysql5.6 was 250,000 queries per second, which was also the best result we got by using SQL query on Mysql/InnoDb during that time. Of course, such a high speed can only be achieved by using the 'read-only transaction' function (a new function on Mysql5.6); in addition, AUTOCOMMIT=1 needs to be used, otherwise the CPU will be easily wasted on starting transactions and committing transactions, You will actually lose the overall performance of the system. So, the first improvement introduced on Mysql5.7 is the 'auto-discovery of read-only transactions' (actually every InnoDb transaction is considered read-only until there is a DML declaration outside of it) feature --- , which greatly simplifies the read-only transaction function, saving users and developers time, they no longer have to manage whether to use the read-only transaction function. However, using this feature you still can't achieve the best possible query rate per second of Mysql, because the CPU time is still wasted in the process of opening and closing the state of the transaction. |
Translated by Wang Ruiping
|
|
At the same time, Percona uses different solutions to solve the problem of "transaction list" management (TRX-list) and slow trx_sys mutex link in InnoDB. Percona's solution works well under high load with transactional Point-Selects, but MySQL 5.7 is mediocre (but I won't post results for 5.7 because its code is not public)... So, at least I can now Do some comparisons:
Observation results:
|
Translated by yale8848
|
|
Clearly, however, transactions should be avoided if the maximum potential query-per-second rate is desired with MySQL. Let's take a look at this is our maximum query rate per second in May 2013. Tested with eight tables at the same point, but nothing using MySQL 5.6:
Observed:
|
Translated by NCThinker
|
|
而在MySQL5.7上做同样的测试却看起来大有不同，因为在5.7中lock_sys互斥链接的时间段已经很低了，同时trx_sys互斥相关代码也得到第一次变化的情形：
观察结果：
|
yale8848
|
|
从另一方面来讲，仍然有改进的空间这点还是很清晰的。有关trx_sys的争用仍然在持续。我们没有充分的使用CPU的能力来做有用的工作（仍然有许多CPU周期用在锁的轮转）...不过现在的结果比以前好多了，并且比5.6好很多，因此没有理由继续挖掘来提高这方面的性能，我们主要集中在我们曾经花费了巨大的空间的读写负载的性能提高上。 到了5月底，也就是我们的性能会议期间，Sunny给try_sys互斥争用增加了几个新的更改，从那以后最大的每秒可进行的查询（QPS）可达到375K！这是不是对5.7进行了足够的性能提高，对吗？;-) 同时，我们继续与建议用其他方式管理TRX列表的Percona团队交换了意见，他们的方案看起来非常有趣，不过在5.5上，这样的代码却不能展示出更高的每秒可进行的查询数（QPS），而且在5.6上的这样代码（曾经测试过Percona Server 5.6）最大的每秒可进行的查询数（QPS）也不会比在MySQL 5.6上大。然而，讨论涉及到一个有趣的观点：如果同时有一些读写负载在运行的话，它对只读性能有什么影响呢？...而且，即使在同样的测试条件下MySQL 5.7代码仍然运行的要好一些，效果是非常明显的（你可以在这儿查看我的分析，然而，再次说明一下，这段时间内我不能展示５.7上的结果，因为它的代码还没有对大众公布－也许会在以后的一篇文章中给出）.. |
几点人
|
|
由于这儿同时对任何纯粹的读写负载也有影响，因此有足够的动机以Sunnys很长时间所期待的那样重新写整个TRX列表相关的代码，然而，这种经历简直让人痴迷！
;-)) 日复一日，我们很高兴的看到我们的每秒可进行的查询图逐渐变高，直到在同一个32核的超线程服务器上达到了每秒可进行的查询440K! 5.7开发里程碑发布2上进行的Select 8个表所得到的结果数：
不需要说明..;-)) 然而，有一个小小的令人奇怪的地方－我们试图与Sunny通过不同的工具分析所有瓶颈和代码更改所带来的影响。而且在某些测试里，令我吃惊的是Sunny观察到比我更高的每秒可进行的查询数..这个“奇异之处”与下面因素相关：
|
几点人
|
|
让我们来比较“之前”和“之后”的差异
观察结果：
还有什么呢？ 我可能只提到：kudos Sunny和整个MySQL的开发团队； 让我们看一下现在选择8张表工作负载的情况下的最大每秒查询。
每个引擎都在以下配置下进行测试：
|
NCThinker
|
|
最好的结果是来自任意两个特定的组合间的比较。通过对数据库引擎的比较，我得到了下面的一个图表，这个图表我在以前的文章中已经提到过了。
具有什么样的扩展性呢？
答案是简单的：MySQL5.7是唯一在此基础上进行扩展的。 如果使用ip端口和一个重量级的Sysbench-0.4.13，会得到如下的结果：
QPS只是稍微的略低一点，但是总体的趋势是完全一样的。 可扩展性也是非常的相似：
更多的结果将会出来，敬请期待； 注意：对一个单表绑定过多的工作负载是不好的：
|
NCThinker
|
下面是一些评论：
|
还有很多挑战摆在我们面前;-) 作为参考，我上述测试的硬件配置信息如下：
my.conf: max_connections=4000 key_buffer_size=200M low_priority_updates=1 table_open_cache = 8000 back_log=1500 query_cache_type=0 table_open_cache_instances=16 # files innodb_file_per_table innodb_log_file_size=1024M innodb_log_files_in_group = 3 innodb_open_files=4000 # buffers innodb_buffer_pool_size=32000M innodb_buffer_pool_instances=32 innodb_additional_mem_pool_size=20M innodb_log_buffer_size=64M join_buffer_size=32K sort_buffer_size=32K # innodb innodb_checksums=0 innodb_doublewrite=0 innodb_support_xa=0 innodb_thread_concurrency=0 innodb_flush_log_at_trx_commit=2 innodb_max_dirty_pages_pct=50 innodb_use_native_aio=1 innodb_stats_persistent = 1 innodb_spin_wait_delay= 6 / 96 # perf special innodb_adaptive_flushing = 1 innodb_flush_neighbors = 0 innodb_read_io_threads = 4 innodb_write_io_threads = 4 innodb_io_capacity = 4000 innodb_purge_threads=1 innodb_adaptive_hash_index=0 # monitoring innodb_monitor_enable = '%' performance_schema=OFF 如果你需要的话，Linux Sysbench的二进制版本在这里：
使用UNIX socket来运行Point-Selects测试的Sysbench命令如下（在parallel中启动8个进程）： LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.8 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-socket=/SSD_raid0/mysql.sock \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &
使用IP端口来运行Point-Selects测试的Sysbench命令如下（在parallel中启动8个进程）： LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.13 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-host=127.0.0.1 --mysql-port=5700 \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &
Good luck to you, -Dimitri |