版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sun_ashe/article/details/84314866
20亿数据Innodb表的测试报告
Innodb表最大可以承载64TB的数据，按照sysbench的标准表结构，20亿数据大概在400多GB，所以这样的表，Innodb是可以处理的，只不过是性能的问题，那么这个性能到底会有多差呢？
400G数据基本上已经超过市面上绝大部分的服务器内存了，所以数据不能完全被缓存，巨大的IO压力，将会是影响性能的主要原因。
一、软硬件信息
硬件
- CPU
2*Intel Xeon E5-2698 v3 2.3GHz,40M 缓存,9.60GT/s QPI,无Turbo,无 HT,16C/6T (135W)
- 内存
256G内存,型号频率未知
- 机械硬盘
6*600G/SAS/10K,RAID1+0
- ssd硬盘
10*480G Intel S3510
- RAID卡
H730P
- 网卡
千兆网卡*2 + 万兆(Intel x520 芯片组82599ES,需要光模块)光口*4
- 电源
750W*2
软件
- MySQL
5.7.18-log 官方二进制版本
- OS
CentOS release 6.5 (Final)
- 内核
Linux 100-110-0-9 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
- sysbench
sysbench 1.0.11 最新release版本，自编译。
- 测试模型
标准oltp测试模型，如下:
1 transaction =
10 select_simple_id +
1 select_between_id +
1 select_sum_between_id +
1 select_between_id_order_noindex+
1 select_distinct_between_id_order_noindex +
2 update_simple_id +
1 delete_simple_id +
1 insert
二、核心参数设置
数据库
innodb_flush_log_at_trx_commit=1
innodb_adaptive_flushing=on
innodb_flush_neighbors=1
innodb_flushing_avg_loops=30
binlog_group_commit_sync_delay=0
binlog_group_commit_sync_no_delay_count=0
binlog_order_commits=on
sync_binlog=1
binlog_cache_size=1048576
操作系统
- 内核相关
kernel.shmall=4294967296
net.ipv4.tcp_rmem=10240 87380 16777216
net.ipv4.tcp_wmem=10240 87380 16777216
net.ipv4.tcp_mem=10240 87380 16777216
net.core.rmem_default=524287
net.core.wmem_default=524287
net.core.rmem_max=524287
net.core.wmem_max=524287
net.core.optmem_max=524287
net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_keepalive_time=600
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1025 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 300000
vm.swappiness = 0
fs.aio-max-nr = 262144
- 磁盘相关
// 挂载
UUID=410cde86-1d36-413b-abb3-8d54a7c322a1 / ext4 defaults 1 1
UUID=5252f6b3-191a-4214-b3ae-a98743465473 /boot ext4 defaults 1 2
UUID=b0c100ae-693e-41b2-b567-dca0a66628ad /data ext4 defaults,noatime,nodiratime,nobarrier 1 2
UUID=c66b48e3-ea20-4498-bd96-0b8520eab9f4 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
UUID=31efb086-005f-4b28-98d9-b9e67cbba136 /dbdata ext4 defaults,noatime,nodiratime,nobarrier 0 0
//调度算法
cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
三、机械硬盘下的标准OLTP测试
在不同并发下的表现如下
mysql> select *from test_oltp where disk_type='machine' and thread_num%20=0 order by thread_num;
+-----+------------+-----------+------+------+-----------------+---------------------+-----------+
| id | thread_num | test_mode | qps | tps | mysql_mode | insert_time | disk_type |
+-----+------------+-----------+------+------+-----------------+---------------------+-----------+
| 21 | 20 | oltp.lua | 2082 | 104 | single_table_2G | 2018-11-20 12:52:46 | machine |
| 41 | 40 | oltp.lua | 2503 | 125 | single_table_2G | 2018-11-20 13:12:52 | machine |
| 61 | 60 | oltp.lua | 2788 | 139 | single_table_2G | 2018-11-20 13:33:01 | machine |
| 81 | 80 | oltp.lua | 2906 | 145 | single_table_2G | 2018-11-20 13:53:12 | machine |
| 101 | 100 | oltp.lua | 3426 | 171 | single_table_2G | 2018-11-20 14:13:24 | machine |
| 121 | 120 | oltp.lua | 3461 | 173 | single_table_2G | 2018-11-20 14:33:37 | machine |
| 141 | 140 | oltp.lua | 3413 | 170 | single_table_2G | 2018-11-20 14:53:56 | machine |
| 161 | 160 | oltp.lua | 3598 | 179 | single_table_2G | 2018-11-20 15:14:19 | machine |
| 181 | 180 | oltp.lua | 2976 | 148 | single_table_2G | 2018-11-20 15:34:54 | machine |
| 201 | 200 | oltp.lua | 2918 | 145 | single_table_2G | 2018-11-20 15:56:05 | machine |
| 221 | 220 | oltp.lua | 3883 | 194 | single_table_2G | 2018-11-20 16:18:18 | machine |
| 241 | 240 | oltp.lua | 5161 | 258 | single_table_2G | 2018-11-20 16:39:54 | machine |
+-----+------------+-----------+------+------+-----------------+---------------------+-----------+
12 rows in set (0.00 sec)
从测试结果上来看，这个配置下，单表20亿的数据，在sql优化很好的情况下也能达到5000的qps，对于一般的业务而言，也是足够了。但是业务高峰期，如果上层不进行限流处理，数据库就扛不住了。
压测到256线程之后便没有继续增加线程数，因为数据库中已经出现大于3秒的查询了，这种状况下，服务质量极低，没有oltp的实际意义。
四、SSD硬盘下的标准OLTP测试
机械硬盘的表现不太好，是因为机械硬盘在处理大量的随机IO时确实有点吃力，而这是SSD的强项。下面看在SSD下的sysbench结果。
mysql> select *from test_oltp where disk_type='ssd' and thread_num%1=0 order by thread_num;
+-----+------------+-----------+-------+------+-----------------+---------------------+-----------+
| id | thread_num | test_mode | qps | tps | mysql_mode | insert_time | disk_type |
+-----+------------+-----------+-------+------+-----------------+---------------------+-----------+
| 258 | 1 | oltp.lua | 3262 | 163 | single_table_2G | 2018-11-20 19:06:48 | ssd |
| 259 | 1 | oltp.lua | 4262 | 213 | single_table_2G | 2018-11-20 19:08:44 | ssd |
| 260 | 2 | oltp.lua | 8273 | 413 | single_table_2G | 2018-11-20 19:09:44 | ssd |
| 261 | 3 | oltp.lua | 12218 | 610 | single_table_2G | 2018-11-20 19:10:44 | ssd |
| 262 | 4 | oltp.lua | 15918 | 795 | single_table_2G | 2018-11-20 19:11:44 | ssd |
| 263 | 5 | oltp.lua | 17323 | 866 | single_table_2G | 2018-11-20 19:12:44 | ssd |
| 264 | 6 | oltp.lua | 21020 | 1051 | single_table_2G | 2018-11-20 19:13:44 | ssd |
| 265 | 7 | oltp.lua | 24146 | 1207 | single_table_2G | 2018-11-20 19:14:44 | ssd |
| 266 | 8 | oltp.lua | 26914 | 1345 | single_table_2G | 2018-11-20 19:15:44 | ssd |
| 267 | 9 | oltp.lua | 30091 | 1504 | single_table_2G | 2018-11-20 19:16:44 | ssd |
| 268 | 10 | oltp.lua | 32977 | 1648 | single_table_2G | 2018-11-20 19:17:44 | ssd |
| 269 | 11 | oltp.lua | 35674 | 1783 | single_table_2G | 2018-11-20 19:18:44 | ssd |
| 270 | 12 | oltp.lua | 39396 | 1969 | single_table_2G | 2018-11-20 19:19:44 | ssd |
| 271 | 13 | oltp.lua | 38506 | 1925 | single_table_2G | 2018-11-20 19:20:44 | ssd |
| 272 | 14 | oltp.lua | 43569 | 2178 | single_table_2G | 2018-11-20 19:21:45 | ssd |
| 273 | 15 | oltp.lua | 45042 | 2252 | single_table_2G | 2018-11-20 19:22:45 | ssd |
| 274 | 16 | oltp.lua | 48986 | 2449 | single_table_2G | 2018-11-20 19:23:45 | ssd |
| 275 | 17 | oltp.lua | 50438 | 2521 | single_table_2G | 2018-11-20 19:24:45 | ssd |
| 276 | 18 | oltp.lua | 55287 | 2764 | single_table_2G | 2018-11-20 19:25:45 | ssd |
| 277 | 19 | oltp.lua | 57597 | 2879 | single_table_2G | 2018-11-20 19:26:45 | ssd |
| 278 | 20 | oltp.lua | 56368 | 2818 | single_table_2G | 2018-11-20 19:27:45 | ssd |
| 279 | 21 | oltp.lua | 61177 | 3058 | single_table_2G | 2018-11-20 19:28:45 | ssd |
| 280 | 22 | oltp.lua | 64741 | 3237 | single_table_2G | 2018-11-20 19:29:45 | ssd |
| 281 | 23 | oltp.lua | 64426 | 3221 | single_table_2G | 2018-11-20 19:30:46 | ssd |
| 282 | 24 | oltp.lua | 67117 | 3355 | single_table_2G | 2018-11-20 19:31:46 | ssd |
| 283 | 25 | oltp.lua | 70912 | 3545 | single_table_2G | 2018-11-20 19:32:46 | ssd |
| 284 | 26 | oltp.lua | 72211 | 3610 | single_table_2G | 2018-11-20 19:33:46 | ssd |
| 285 | 27 | oltp.lua | 73334 | 3666 | single_table_2G | 2018-11-20 19:34:46 | ssd |
| 286 | 28 | oltp.lua | 72365 | 3618 | single_table_2G | 2018-11-20 19:35:46 | ssd |
| 287 | 29 | oltp.lua | 74110 | 3705 | single_table_2G | 2018-11-20 19:36:47 | ssd |
| 288 | 30 | oltp.lua | 71601 | 3580 | single_table_2G | 2018-11-20 19:37:47 | ssd |
| 289 | 31 | oltp.lua | 72964 | 3648 | single_table_2G | 2018-11-20 19:38:47 | ssd |
| 290 | 32 | oltp.lua | 74124 | 3706 | single_table_2G | 2018-11-20 19:39:47 | ssd |
| 291 | 33 | oltp.lua | 75373 | 3768 | single_table_2G | 2018-11-20 19:40:47 | ssd |
| 292 | 34 | oltp.lua | 74907 | 3745 | single_table_2G | 2018-11-20 19:41:47 | ssd |
| 293 | 35 | oltp.lua | 74336 | 3716 | single_table_2G | 2018-11-20 19:42:47 | ssd |
| 294 | 36 | oltp.lua | 74429 | 3721 | single_table_2G | 2018-11-20 19:43:48 | ssd |
+-----+------------+-----------+-------+------+-----------------+---------------------+-----------+
37 rows in set (0.00 sec)
目前测试还在进行中，本次只是初步测试，便可以发现，SSD在这种大量的随机读写IO中的巨大优势。在业务SQL相对优化的情况下，上10w的QPS，应该可以满足绝大部分业务了吧，当然一线电商是满足不了的。
测完了，看下机械硬盘vs固态硬盘的结果，下面是一组横向对比数据，可以看出来，差的可不止10倍。
mysql> select a.thread_num,a.qps,a.tps,a.disk_type,b.qps,b.tps,b.disk_type from test_oltp a inner join test_oltp b on a.thread_num=b.thread_num where a.disk_type='machine' and b.disk_type='ssd' and a.thread_num%20=0;
+------------+------+------+-----------+--------+------+-----------+
| thread_num | qps | tps | disk_type | qps | tps | disk_type |
+------------+------+------+-----------+--------+------+-----------+
| 20 | 2082 | 104 | machine | 56368 | 2818 | ssd |
| 40 | 2503 | 125 | machine | 76120 | 3806 | ssd |
| 60 | 2788 | 139 | machine | 87157 | 4357 | ssd |
| 80 | 2906 | 145 | machine | 96059 | 4802 | ssd |
| 100 | 3426 | 171 | machine | 103976 | 5198 | ssd |
| 120 | 3461 | 173 | machine | 106682 | 5334 | ssd |
| 140 | 3413 | 170 | machine | 115700 | 5785 | ssd |
| 160 | 3598 | 179 | machine | 109967 | 5498 | ssd |
| 180 | 2976 | 148 | machine | 108453 | 5422 | ssd |
| 200 | 2918 | 145 | machine | 108036 | 5401 | ssd |
| 220 | 3883 | 194 | machine | 108844 | 5442 | ssd |
| 240 | 5161 | 258 | machine | 110180 | 5509 | ssd |
+------------+------+------+-----------+--------+------+-----------+
12 rows in set (0.01 sec)
五、总结
SSD在这种场景下无疑吊打机械硬盘，下篇会就机械硬盘下如何进行大表的优化进行测试和探讨。