MySQL MyISAM磁盘绑定扩展问题/驱动器缓存

时间:2009-10-30 12:14:04

标签: mysql caching ubuntu disk myisam

我有以下查找表:

CREATE TABLE `widgetuser` (
 `widgetuserid` char(40) NOT NULL,
 `userid` int(10) unsigned NOT NULL,
 `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 PRIMARY KEY (`widgetuserid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 DELAY_KEY_WRITE=1;

我有一个widgetuser_tmp表,结构相同但没有键,我用这个数据填充widgetuser表(4mio行):

mysql> insert into widgetuser select * from widgetuser_tmp limit 0,4000000;flush tables;
Query OK, 4000000 rows affected (33.14 sec)
Records: 4000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (0.91 sec)

在编写时,它直接以15MB / s的速度直接进入RAID-1,磁盘使用率<50%,我们看不到任何读取,因为我用源表填充了磁盘缓存:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00  3839.20    0.00   52.40     0.00    15.20   594.20    12.46  237.75   5.57  29.20
sdb               0.00  3839.00    0.00   52.60     0.00    15.20   591.94    14.50  275.59   7.19  37.80

我插入了下一个1 Mio行,一切正常,刷新后wMB / s回到0:

mysql> insert into widgetuser select * from widgetuser_tmp limit 4000000,1000000;flush tables;
Query OK, 1000000 rows affected (10.18 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (0.87 sec)

mysql> insert into widgetuser select * from widgetuser_tmp limit 5000000,1000000;flush tables;
Query OK, 1000000 rows affected (10.21 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (1.02 sec)

mysql> insert into widgetuser select * from widgetuser_tmp limit 6000000,1000000;flush tables;
Query OK, 1000000 rows affected (10.67 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (1.17 sec)

但是当我进行7mio批处理时,结果看起来仍然相同,但在iostat -mdx sda sdb 5突然我们有100%的效率30秒:

mysql> insert into widgetuser select * from widgetuser_tmp limit 7000000,1000000;flush tables;
Query OK, 1000000 rows affected (10.73 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (1.21 sec)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    88.60    0.00  295.60     0.00     1.52    10.53   130.60  435.93   3.38 100.00
sdb               0.00    89.20    0.00  300.80     0.00     1.57    10.68   143.99  483.97   3.32 100.00

刷新后不会触及数据文件:

-rw-rw---- 1 mysql mysql 1032000000 2009-10-30 12:10 widgetuser.MYD
-rw-rw---- 1 mysql mysql  522777600 2009-10-30 12:11 widgetuser.MYI  

并且表状态接缝正常:

+----------------+--------+---------+------------+----------+----------------+-------------+-------------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+-------------------+---------+
| Name           | Engine | Version | Row_format | Rows     | Avg_row_length | Data_length | Max_data_length   | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation       | Checksum | Create_options    | Comment |
+----------------+--------+---------+------------+----------+----------------+-------------+-------------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+-------------------+---------+
| widgetuser     | MyISAM |      10 | Fixed      |  8000000 |            129 |  1032000000 | 36310271995674623 |    522777600 |         0 |           NULL | 2009-10-30 11:59:41 | 2009-10-30 12:10:59 | NULL       | utf8_general_ci |     NULL | delay_key_write=1 |         |
+----------------+--------+---------+------------+----------+----------------+-------------+-------------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+-------------------+---------+

当我继续(因为我们有100%的驱动器利用率)时,它变得非常快:

mysql> insert into widgetuser select * from widgetuser_tmp limit 9000000,1000000;flush tables;
Query OK, 1000000 rows affected (31.93 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (2.34 sec)

mysql> insert into widgetuser select * from widgetuser_tmp limit 10000000,1000000;flush tables;
Query OK, 1000000 rows affected (2 min 39.72 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (7.82 sec)

检查主键以查看新条目是否唯一。一旦密钥不适合内存(key_buffer_size = 512MB = ca. 8Mio条目),它就需要从驱动器(-cache)中获取缺少的密钥部分以进行检查。因此,我们应该看到更多的读取和更慢的插入时间 - 我们没有看到较慢的读取,因为密钥缓存在磁盘缓存中。但我的问题是:谁突然写了这么多,在哪里以及为什么以及如何解决这个问题?任何想法都表示赞赏!

更多的想法和见解:

  • 由于1MB / s的随机写入遵循完成的语句,因此已经通过了唯一的验证
  • 它是一个带有ahci的软件raid-1,磁盘是93%免费的,能够达到80wMB / s
  • 该机器有8GB RAM,5GB缓存,MySQL占用600MB,免费1,7GB
  • MySQL 5.1.31-1ubuntu2-log
  • delay_key_write不会改变此行为
  • myisam_sort_buffer_size = 2 GB(这里不使用?)
  • key_buffer_size = 512 MB
  • bin_log已关闭
  • Linux 2.6.28-15-server#52-Ubuntu SMP Wed Sep 9 11:34:09 UTC 2009 x86_64 GNU / Linux

2 个答案:

答案 0 :(得分:1)

从你的问题来看,你所期待或得到的行为并不完全清楚。以下是您可能不知道的一些事情

  • FLUSH TABLES吹走了MyISAM密钥缓存 - 它不只是写脏块,它也会丢弃干净的块,因此必须再次获取每个索引块以进行修改
  • MyISAM默认使用1k的块大小,可能比文件系统块小;这可能会造成性能问题
  • 如果您想要任何类型的持久性(您可能不会,因为您正在使用MyISAM),那么您应该在控制器中使用硬件raid和电池备份缓存。

我的猜测是,索引不再适合密钥缓冲区,或者它必须执行更多写操作,这会触发读取,因为它们是无缓冲的写入块大小边界。

尝试将myisam_block_size更改为4k或更高版本并重建表格(这是一个my.cnf-only选项,仅在重新启动后对新表生效)。

您可以使用myisamchk -dv

检查表格上的块大小

答案 1 :(得分:0)

我正在使用mariadb5528,如果使用key_buffer_size> 90%,似乎delay_key_write不起作用 所以将key_buffer_size放大到2G。