20億資料Innodb表的OLTP測試報告
阿新 • • 發佈：2018-11-21
文章目錄
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在這種場景下無疑吊打機械硬碟，下篇會就機械硬碟下如何進行大表的優化進行測試和探討。