0

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

我们有一个“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 小时后，数据就在我预期的位置。

4

4 回答 4

1

对于您的 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_pa​​cket 不太可能是合理的。

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

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

要进行更彻底的分析，请提供从属和主控 RAM 大小 (nnG)

SHOW GLOBAL STATUS
SHOW GLOBAL VARIABLES
SHOW INNODB STATUS
于 2017-08-13T08:26:05.037 回答
1

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

于 2017-07-28T15:49:50.160 回答
0

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

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

于 2017-08-15T06:43:19.203 回答
0

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

为了利用 100% cpu，请考虑生成 2 个 PHP 脚本，它们在 2 个单独的数据集上工作 - 例如，脚本 1 处理记录 1-1000000，而脚本 2 处理 1000001-2000000。

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

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

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

于 2017-07-28T14:02:31.100 回答