Question

我正在开发一个类似社交的应用程序，目前使用AWS服务进行部署。特别是，DB使用MYSQL在RDS上运行。到目前为止，我们使用有限数量的用户（主要是朋友）测试应用程序，平均每秒写入10次写入IOPS。

真正的问题与db的非常高的写入延迟有关，它始终高于100ms。 RDS实例是db.m3.xlarge，远远超出我们的需要。

我尝试在单独的实例中执行负载测试（DB和EC2的相同配置），但即使我发送了更多的请求，我也无法重现如此高的延迟。所以我认为这可能是由于表碎片，但我还没有运行表优化，因为在此过程中无法访问db。

您对这个问题有经验吗？

更多信息

我们使用mysql版本5.6.21和INNODB作为存储引擎。
整个数据库大小约为100MB

最大的表（称为Message）大约有790k行。关于此表，以下查询

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)

花了14秒，但表评论大约有160k。

这两个表由：

生成

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       |
+------------------------------+-----------+

感谢您的帮助！

安德烈

Answer 1

我与亚马逊的RDS工程师取得了联系，他们给了我解决方案。这种高延迟是由于存储类型非常低。实际上，我使用默认的5GB SSD（他们称之为GP2），每GB存储空间可提供3 IOPS，当我的应用程序需要大约50 IOPS甚至更高时，会产生15 IOPS。

因此，他们建议我将存储类型更改为Magnetic，它提供100 IOPS作为基线。此外，我还能够减少实例类型，因为瓶颈只是磁盘。

由于源磁盘（GP2）的性能非常低，迁移大约耗时3小时。

希望它可以帮助那些人！

Answer 2

您的查询个人资料显示＆＃34;查询结束＆＃34;时间非常长。这可能是由非常（太大）query cache引起的。每次执行更新语句（INSERT，DELETE，UPDATE）时，都必须更新查询缓存（从更新的表中读取的每个查询都将失效）。

MySQL高写延迟

2 个答案: