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

Question

我有以下查找表：

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% util 持续 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 内存、5GB 缓存、MySQL 占用 600MB、1,7GB 可用
• MySQL 5.1.31-1ubuntu2-log
• 延迟_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

Answer 1

从您的问题中尚不完全清楚您期望或得到什么行为。以下是您可能不知道的一些事情

• FLUSH TABLES 会破坏 MyISAM 键缓存 - 它不仅会写入脏块，还会丢弃干净的块，因此必须再次获取每个索引块才能进行修改
• MyISAM 使用 1k 的块大小默认值可能小于您的文件系统块；这可能会产生性能问题
• 如果您想要任何类型的持久性（您可能不这样做，因为您使用的是 MyISAM），那么您应该在控制器中使用带有电池支持缓存的硬件 raid。

我的猜测是，要么索引不再适合键缓冲区，要么它必须执行更多写入操作，这会触发读取，因为它们是无缓冲的，会超出块大小边界。

尝试将 myisam_block_size 更改为 4k 或更高并重建表（这是仅 my.cnf 的选项，仅在重新启动后对新表生效）。

您可以使用 myisamchk -dv 检查表上的块大小

Answer 2

我正在使用mariadb5528，如果key_buffer_size的使用率> 90％，似乎delay_key_write不起作用
所以将key_buffer_size扩大到2G。