谷歌云sql不正确innodb_buffer_pool_size？答案

【问题标题】：Google cloud sql incorrect innodb_buffer_pool_size?谷歌云sql不正确innodb_buffer_pool_size？
【发布时间】：2019-05-10 17:22:54
【问题描述】：

上周我将我的 Cloud SQL 机器从“db-f1-micro”0.6GB RAM 机器升级到“db-n1-standard-1”3.75GB RAM 机器。运行：

SELECT @@innodb_buffer_pool_size;

输出是：

1375731712

我相信是 1.38GB。以下是主副本和副本的内存利用率：

对于这种机器类型来说，这似乎有点低，但研究 (How to set innodb_buffer_pool_size in mysql in google cloud sql?) 似乎我无法更改 innodb_buffer_pool_size。这是否以某种方式动态设置并随着时间缓慢增加？似乎没有接近谷歌似乎针对这些目标的 75-80% 范围。

【问题讨论】：

您的数据集有多大？一件事是它可能还没有完全缓存。正如您所说，内存使用量正在增加。您可以尝试使用mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status'; 检查此调整大小过程，如MySQL docs 所示。
运行以上返回零行。数据库由 25 个左右的表组成。大多数表小于 20,000 行，但其中一个较大的表有大约 4800 万行。很少有其他人每个都有 1000 万行。

标签： google-cloud-sql

【解决方案1】：

innodb_buffer_pool_chunk_size 和 innodb_buffer_pool_instances 的值是多少？

innodb_buffer_pool_size 必须始终等于或为这两个值的乘积的倍数，并且会自动调整为这样。块大小只能在启动时修改，如the docs page for InnoDB Buffer Pool Size configuration 中所述。

特别是对于 Google CloudSQL，innodb_buffer_pool_size 的绝对大小和相对大小都取决于实例类型。我为 GCP 支持工作，在对我们的文档进行一些研究之后，我可以看出池大小是根据内部公式自动配置的，该公式可能会发生变化。正在进行改进以使实例对 OOM 更具弹性，而缓冲池大小在其中起着重要作用。

因此，对于您的新实例类型，以及可能不同的innodb_buffer_pool_chunk_size 和innodb_buffer_pool_instances，您的内存使用量可能会发生很大变化，这是预期的行为。目前，用户无法控制innodb_buffer_pool_size。

【讨论】：

嗨@alextru，innodb_buffer_pool_chunk_size 回来了：未知系统变量'innodb_buffer_pool_chunk_size' 而innodb_buffer_pool_instances 返回1
您的实例是否使用 MySQL 5.6？我已经看到 innodb_buffer_pool_chunk_size 没有出现在该版本的变量引用表中，但它出现在 5.7 版本中。所以你需要升级你的 MySQL 版本来检查这个值。您还可以尝试将缓冲池实例的数量增加到 2 个，以减少争用。之后池大小可能会重新调整。见this page。
升级到 5.7 对我们来说不是一个现实的选择。这是一个实时的 PROD 实例，验证升级到 5.7 所需的回归测试没有破坏任何东西，不值得为可能访问 innodb_buffer_pool_chunk_size 变量而付出努力。
我明白了。好吧，无论如何，如果您想更改innodb_buffer_pool_chunk_size 和innodb_buffer_pool_instances，您必须重新启动实例并指定新值。