Google Cloud SQL 很慢：10GB RAM 的 mysql 实例比配置 125MB ram 的 Macbook Pro 慢 20 倍

Posted 2023-02-24

【中文标题】Google Cloud SQL 很慢：10GB RAM 的 mysql 实例比配置 125MB ram 的 Macbook Pro 慢 20 倍

【英文标题】：Google Cloud SQL is SLOW: mysql instance with 10GB RAM is 20x slower than Macbook Pro configured with 125MB ram

【发布时间】：2019-06-27 10:29:20

【问题描述】：

我们根据 Google Cloud SQL 指令转储了我们的表，并将其导入到第二代 Google Cloud SQL 实例中。

我们很高兴看到我们的数字将如何在“谷歌硬件”上运行。

在使用 Apache ab 对我们的 Rails 应用程序进行压力测试后，完成时间增加了 150 毫秒，我们注意到 ActiveRecord 在相同页面中比我们的生产服务器（裸机）多花 30 毫秒到 50 毫秒。

当我们深入挖掘时，真正让我们大吃一惊的是像这样的简单计数查询：

GOOGLE CLOUD SQL - db-n1-standard-4 (4vcpu and 15GB RAM)

1. Cold query

mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
|  3998050 |
+----------+
1 row in set (19.26 sec)

2. Repeat query

mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
|  3998050 |
+----------+
1 row in set (1.16 sec)

SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
|                          10.500000000000 |
+------------------------------------------+
1 row in set (0.00 sec)

然后我可以多次重复查询并且性能是相同的。

在我的 macbook pro 2017 中使用完全相同的转储运行相同的查询：

MACBOOK PRO 2017

1. Cold query

mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
|  3998050 |
+----------+
1 row in set (1.51 sec)

2. Repeat query

mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
|  3998050 |
+----------+
1 row in set (0,51 sec)

SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
|                           0.125000000000 |
+------------------------------------------+
1 row in set (0,03 sec)

更荒谬的是，正如您在上面看到的，我没有对我的默认 mysql 安装进行任何调整，所以它在我的 Macbook 中只使用了 125MB 的 RAM，而 Google Cloud 实例有 10GB 的 RAM可用。

我们尝试将 Google Cloud SQL 实例大小增加到 db-n1-highmen-8（8vCPU 和 52GB 内存！）以不增加性能（如果我们从 db-n1-standard-4 减少，我们确实会看到表现）。

最后但并非最不重要的一点是，使用this question 我们可以确认我们的数据库只有 46GB，但在导入期间，谷歌云 sql 中的存储使用量一直在增长，直到达到荒谬的 74GB...我们不知道这是不是因为二进制日志记录（默认情况下在谷歌云 SQL 上打开，在我的本地机器上关闭）。

那么 .. 没有人在生产中使用 Google Cloud sql 吗？ :)

更新：我们使用完全相同的 .sql 转储并将其加载到 db.r4.large AWS RDS（因此相同的 cpu / ram）并在查询中获得一致的 0.50 秒性能，而且它在实例中消耗的空间也不超过 46GB。

【问题讨论】：

Binlog 是罪魁祸首superuser.com/questions/848514/…

@Hackerman 不，不是。我们关闭了 binlogging（这是控制台中的一个简单复选框），重启后结果如下： First COUNT（我称之为“冷查询”）：9.84sec；其他计数（尝试 > 10 次，结果一致）：平均 1.14 秒。

嘿伙计，我正在经历同样的事情。有什么解决办法吗？就我而言，我在一个带有数字海洋的外部服务器中，当我将我的谷歌云 sql 连接到我的应用程序时，我发现它超级慢。

@NicoZarris 因为我们在比较 AWS x Google Cloud，所以我们只是决定使用 AWS 了解并没有进一步挖掘（请参阅更新后的问题，在 AWS 中，我们拥有最佳性能）盒子）。糟糕的是，对于南美洲，AWS 的带宽成本是 GC 的 2 倍以上。

另外，用于 MySql 的 google cloud sql 默认使用 GTID 复制，这绝对是导致性能下降的一个重要因素。 cloud.google.com/sql/docs/mysql/1st-2nd-gen-differences

【参考方案1】：

比较执行计划（前置EXPLAIN），您可能会发现一些显着的实现差异是由于超出缓冲池大小的配置参数变化造成的。

我在周末设置 Postgres Cloud SQL 数据库时遇到了类似的问题，其中包含约 100gb 的数据，在我的 macbook pro 上镜像本地数据库。对于使用索引的非常有针对性的选择，性能与我的本地数据库相当，但扫描大量数据的查询速度要慢 2-5 倍。

比较本地和云实例之间SHOW ALL（我认为是mysql 中的SHOW VARIABLES）的配置结果，我注意到了一些差异，例如max_parallel_workers_per_gather = Cloud SQL 上的 0 与我本地实例上的 2。

在select count(*)... 的情况下，max_parallel_workers_per_gather 设置 > 0 允许使用 Gather 对使用多个工作人员的并行顺序扫描的结果进行处理；当设置为零时，引擎必须执行一次顺序扫描。对于其他查询，我注意到在我的本地数据库中使用并行工作者的类似趋势，与云实例相比成本更低且速度更快。

这只是促成因素之一；我敢肯定，深入研究设置会发现更多这样的解释。这些是托管服务带来的权衡（尽管对这些参数有更多的控制会很好）。