MySQL 高写入延迟
MySQL High Write Latency
我正在开发一个目前使用 AWS 服务部署的类社交应用程序。特别是 RDS 上的数据库 运行s 使用 MYSQL。
到目前为止,我们正在使用有限数量的用户(主要是朋友)测试该应用程序,结果平均为 15 次写入 IOPS/sec.
真正的问题与数据库的写入延迟非常高有关,总是在 100 毫秒以上。 RDS 实例是一个 db.m3.xlarge 这比我们需要的要多得多.
我尝试在单独的实例(DB 和 EC2 的相同配置)中执行负载测试,但我无法重现如此高的延迟,即使我发送了更多的请求也是如此。所以我认为这可能是由于 table 碎片,但我还没有 运行 table 优化,因为在此过程中无法访问数据库。
您有遇到过这个问题吗?
更多信息
- 我们使用 mysql 版本 5.6.21,INNODB 作为存储引擎。
- 整个数据库大小约为 100MB
最大的 table(称为 Message
)大约有 790k 行。关于这个table,下面的查询
insert into Message (user_id, creationDate, talk_id, text, id)
values (2015, '2015-02-01 16:40:06.737', 18312, 'Some text ', 904870)
需要 11 秒才能执行。
更糟糕的是,查询
insert into Comment (anonymous, user_id, creationDate, deleted, post_id, text, id)
values (1, 107347, '2015-02-01 16:40:01.849', 0, 124888, 'Comment text', 265742)
用了14s,但是table评论有160k左右。
这两个 table 由以下人员生成:
CREATE TABLE `comment` (
`id` bigint(20) NOT NULL,
`anonymous` bit(1) NOT NULL,
`creationDate` datetime NOT NULL,
`deleted` bit(1) NOT NULL,
`text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
`user_id` bigint(20) NOT NULL,
`post_id` bigint(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `FK_jhvt6d9ap8gxv67ftrmshdfhj` (`user_id`),
KEY `FK_apirq8ka64iidc18f3k6x5tc5` (`post_id`),
CONSTRAINT `FK_apirq8ka64iidc18f3k6x5tc5` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`),
CONSTRAINT `FK_jhvt6d9ap8gxv67ftrmshdfhj` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
和
CREATE TABLE `message` (
`id` bigint(20) NOT NULL,
`creationDate` datetime NOT NULL,
`text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
`user_id` bigint(20) NOT NULL,
`talk_id` bigint(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `FK_d0j091jvk2y4mmfbadnqlohtf` (`user_id`),
KEY `FK_64tr15t6wu5y9u143gxt6o3g2` (`thread_id `),
CONSTRAINT `FK_64tr15t6wu5y9u143gxt6o3g2` FOREIGN KEY (`thread_id`) REFERENCES `thread` (`id`),
CONSTRAINT `FK_d0j091jvk2y4mmfbadnqlohtf` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
一些情节
使用 AppDynamics 我已经能够提取以下图:
等待状态:查询结束时间是不是太大了?
页面缓冲区:
写入延迟和队列:
查询缓存
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 1048576 |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+
感谢您的帮助!
安德里亚
您的查询配置文件显示 "Query end" 时间非常长。这可能是由一个非常(太大)大的 query cache 引起的。每次执行更新语句(INSERT、DELETE、UPDATE)时,都必须更新查询缓存(每个从更新表中读取的查询都将失效)。
我联系了亚马逊的 RDS 工程师,他们给了我解决方案。
如此高的延迟是由于性能非常低的存储类型。事实上,我使用的是默认的 5GB SSD(他们称之为 GP2),它为每 GB 存储提供 3 IOPS,当我的应用程序需要大约 50 IOPS 甚至更多时,结果为 15 IOPS。
因此,他们建议我将存储类型更改为 Magnetic
,它提供 100 IOPS 作为基准。此外,我还能够减少实例类型,因为瓶颈只是磁盘。
由于源磁盘 (GP2) 的性能非常低,迁移大约需要 3 小时。
希望它能对外面的人有所帮助!
我正在开发一个目前使用 AWS 服务部署的类社交应用程序。特别是 RDS 上的数据库 运行s 使用 MYSQL。 到目前为止,我们正在使用有限数量的用户(主要是朋友)测试该应用程序,结果平均为 15 次写入 IOPS/sec.
真正的问题与数据库的写入延迟非常高有关,总是在 100 毫秒以上。 RDS 实例是一个 db.m3.xlarge 这比我们需要的要多得多.
我尝试在单独的实例(DB 和 EC2 的相同配置)中执行负载测试,但我无法重现如此高的延迟,即使我发送了更多的请求也是如此。所以我认为这可能是由于 table 碎片,但我还没有 运行 table 优化,因为在此过程中无法访问数据库。
您有遇到过这个问题吗?
更多信息
- 我们使用 mysql 版本 5.6.21,INNODB 作为存储引擎。
- 整个数据库大小约为 100MB
最大的 table(称为
Message
)大约有 790k 行。关于这个table,下面的查询insert into Message (user_id, creationDate, talk_id, text, id) values (2015, '2015-02-01 16:40:06.737', 18312, 'Some text ', 904870)
需要 11 秒才能执行。
更糟糕的是,查询
insert into Comment (anonymous, user_id, creationDate, deleted, post_id, text, id) values (1, 107347, '2015-02-01 16:40:01.849', 0, 124888, 'Comment text', 265742)
用了14s,但是table评论有160k左右。
这两个 table 由以下人员生成:
CREATE TABLE `comment` (
`id` bigint(20) NOT NULL,
`anonymous` bit(1) NOT NULL,
`creationDate` datetime NOT NULL,
`deleted` bit(1) NOT NULL,
`text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
`user_id` bigint(20) NOT NULL,
`post_id` bigint(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `FK_jhvt6d9ap8gxv67ftrmshdfhj` (`user_id`),
KEY `FK_apirq8ka64iidc18f3k6x5tc5` (`post_id`),
CONSTRAINT `FK_apirq8ka64iidc18f3k6x5tc5` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`),
CONSTRAINT `FK_jhvt6d9ap8gxv67ftrmshdfhj` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
和
CREATE TABLE `message` (
`id` bigint(20) NOT NULL,
`creationDate` datetime NOT NULL,
`text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
`user_id` bigint(20) NOT NULL,
`talk_id` bigint(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `FK_d0j091jvk2y4mmfbadnqlohtf` (`user_id`),
KEY `FK_64tr15t6wu5y9u143gxt6o3g2` (`thread_id `),
CONSTRAINT `FK_64tr15t6wu5y9u143gxt6o3g2` FOREIGN KEY (`thread_id`) REFERENCES `thread` (`id`),
CONSTRAINT `FK_d0j091jvk2y4mmfbadnqlohtf` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
一些情节
使用 AppDynamics 我已经能够提取以下图:
等待状态:查询结束时间是不是太大了?
页面缓冲区:
写入延迟和队列:
查询缓存
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 1048576 |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+
感谢您的帮助!
安德里亚
您的查询配置文件显示 "Query end" 时间非常长。这可能是由一个非常(太大)大的 query cache 引起的。每次执行更新语句(INSERT、DELETE、UPDATE)时,都必须更新查询缓存(每个从更新表中读取的查询都将失效)。
我联系了亚马逊的 RDS 工程师,他们给了我解决方案。 如此高的延迟是由于性能非常低的存储类型。事实上,我使用的是默认的 5GB SSD(他们称之为 GP2),它为每 GB 存储提供 3 IOPS,当我的应用程序需要大约 50 IOPS 甚至更多时,结果为 15 IOPS。
因此,他们建议我将存储类型更改为 Magnetic
,它提供 100 IOPS 作为基准。此外,我还能够减少实例类型,因为瓶颈只是磁盘。
由于源磁盘 (GP2) 的性能非常低,迁移大约需要 3 小时。
希望它能对外面的人有所帮助!