计算引擎 MYSQL 服务器 CPU 奇怪答案

【问题标题】：Compute Engine MYSQL Server CPU Strange计算引擎 MYSQL 服务器 CPU 奇怪
【发布时间】：2017-07-28 13:54:36
【问题描述】：

我想不出还有什么可以为这个奇怪的问题命名。

我们有一个“Worker”计算引擎，它是一个 MySQL SLAVE。它的主要作用是处理大量数据，然后将其放回 Master 上。全部通过 PHP 脚本处理。

现在完成数据处理大约需要 4 小时。在此期间，我们注意到以下 CPU 模式。

您在上面看到的是服务器重启后 50% 的稳定 CPU 启动。然后大约 2 小时后，它开始在 CPu 上产生 ECG 样式的图案。大约每 5/6 分钟 CPU 会达到约 48%，然后在 5 分钟内下降。

我的问题是，为什么。任何人都可以解释为什么。理想情况下，我们希望此服务器以 100% 最大化 ots cpu（50%，因为有 2 个内核）

服务器规格：2 个 VCPU，7.5GB 内存。

如前所述，如果我们可以全速运行，那就太好了。下面是my.cnf

symbolic-links=0
max_connections=256
innodb_thread_concurrency = 0
innodb_additional_mem_pool_size = 1G
innodb_buffer_pool_size = 6G
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 800
innodb_flush_method = O_DIRECT
innodb_log_file_size = 24M
query_cache_size = 1G
query_cache_limit = 512M
thread_cache_size = 32
key_buffer_size = 128M
max_allowed_packet = 64M
table_open_cache = 8000
table_definition_cache = 8000
sort_buffer_size = 128M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 128M
tmp_table_size = 256M
query_cache_type = 1
join_buffer_size = 256M
wait_timeout = 300
server-id = 2
relay-log  = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
log-error=/var/log/mysqld.log
read-only = 1
innodb_flush_log_at_trx_commit=2

我已经清理了上述内容，以删除任何带有与性能无关的私人信息的配置。

更新我注意到当 VPU 在图表的心跳部分开始下降时，PHP 脚本不再运行。这是不可能的，因为我知道的脚本需要 4 个小时。没有错误，再过 4 小时后，数据就在我预期的位置。

【问题讨论】：

标签： php mysql google-compute-engine google-console-developer

【解决方案1】：

将 innodb_io_capacity = 800 更改为 1500 可能会通过将限制提高到您知道您可以通过从属处理实现的限制来减少 4 小时的处理时间。

【讨论】：

【解决方案2】：

对于您的 7.5G 指示环境，配置有 innodb_additional_mem_pool_size=1G innodb_buffer_pool_size=6G query_cache_size=1G

所以在你开始之前，你已经过度使用了。

另一个需要考虑的角度 max_connections=256
max_allowed_packet=64M 可能在完全繁忙的 256 个连接上需要 16GB + 才能使此功能存活。 64M 的 max_allowed_packet 不太可能是合理的。

将 read_rnd_buffer_size = 4M 更改为 SET GLOBAL read_rnd_buffer_size=16384; 在您的从属服务器上可能很重要，然后在 24 小时后在主服务器上。它们可能不同，但如果它对减少从属服务器上的 4 小时很重要，请在两个实例上实施。请让我们知道这一单一更改对您有什么影响。

您看到的 50% cpu 利用率是脚本最大化了它能够利用的 --- 单核 --- 。正如最近 PressingOnAlways 所示。您无法调整运行脚本中的限制。

如需更全面的分析，请从 SLAVE AND MASTER 提供 RAM 大小 (nnG)

SHOW GLOBAL STATUS
SHOW GLOBAL VARIABLES
SHOW INNODB STATUS

【讨论】：

谢谢，我会试一试。我仍然不明白为什么图表始终不是 100%。随着过程的运行，它会上下波动。完好无损，似乎该进程会杀死自己并重新开始，就像它自己超载一样？

【解决方案3】：

CPU % 由所有内核测量 - 因此 100% 的 CPU 使用率 == 两个内核都达到最大值。 PHP 默认在单线程中运行，不使用多核。您看到的 50% cpu 利用率是脚本最大限度地利用了它能够利用的单核。

为了利用 100% 的 cpu，请考虑生成 2 个 PHP 脚本，这些脚本适用于 2 个单独的数据集 - 例如脚本 1 处理记录 1-1000000，而脚本 2 处理 1000001-2000000。

其他选项是重写脚本以利用线程。您可能想考虑完全更改语言以获得更有利于线程的东西，例如 Golang？虽然如果主要工作在 mysql 中完成，这可能不是必需的。

当图表低于 50% 时，您看到的另一个问题可能是由于 IO 等待。不过，从图表中很难看出，您可能遇到了数据流传输瓶颈，即您的 CPU 无法工作并在传输大量数据时等待。

优化 CPU 利用率是一种寻找瓶颈并消除瓶颈的练习——祝你好运。

【讨论】：

我理解 50% = 100% 的 1 个核心。如前所述：）感谢您提供有关 CPU 心跳的一些信息。可能是 IO。它运行的 SSD 大约 1,500 IOPS。

【解决方案4】：

“监控服务”可以启用以定期捕获系统的“健康检查”，因为当您看到峰值时，它似乎处于 6 分钟周期。

SHOW GLOBAL STATUS LIKE 'Com_show_%status' 可以确认这种性质的活动。将您的 com_show_%status 计数器除以 (uptime/3600) 以获得每小时费率。每小时 10 次，每 6 分钟一次。

【讨论】：