计算引擎MYSQL服务器CPU奇怪

我想不出还有什么来标题这个奇怪的问题。计算引擎MYSQL服务器CPU奇怪

我们有一个“工人”计算引擎，它是一个MySQL从服务器。它的主要作用是处理大量数据，然后将其放回Master。所有通过PHP脚本处理。

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

什么你可以在上面看到的是一个服务器重新启动后的50％的固体CPU开始。然后在大约2小时后开始在CPu上产生ECG样式。大约每5/6分钟CPU峰值降至〜48％，然后在5分钟内下降。

我的问题是，为什么。请anyoen请解释原因。理想情况下，我们希望此服务器在100％时可以Maxing out cots（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

我已经清除了上面的删除私人信息，这是不相关的任何性能CONFIGS。

UPDATE 的VPU开始PHP脚本不再运行图的心跳节期间下降时，我已经注意到了。这是不可能的，因为我知道的剧本需要4个小时。没有错误，并且在4个小时之后，数据就是我预期的地方。

来源

2017-07-28 Steven Church

CPU％由所有内核测量 - 因此100％cpu使用率==两个内核都最大。默认情况下，PHP运行在一个线程中，不使用多核。你看到的50％CPU利用率是脚本最大化它能够利用的单核。

为了利用100％cpu，考虑产生2个PHP脚本，这些脚本可以在2个独立的数据集上工作 - 例如，脚本1处理记录1-1000000，而脚本2处理1000001-2000000。

其他选项是重写脚本以利用线程。你可能想考虑把语言完全改为更适合线程的东西，比如Golang？尽管如果主要工作在mysql中完成，这可能不是必需的。

当图表低于50％时，您看到的另一个问题可能是由于IO等待。尽管如此，很难从图表中看出，当CPU传输大量数据时，您的CPU可能无法正常工作并等待数据流转移瓶颈。

优化CPU利用率是一个寻找瓶颈和消除瓶颈的练习 - 祝你好运。

来源

2017-07-28 14:02:31 PressingOnAlways

我明白1个核心的50％= 100％。如上所述:)感谢您提供有关CPU心跳信息。可能是IO。其运行SSD约有1,500 IOPS。 –

将innodb_io_capacity = 800更改为1500可能会减少处理4小时所需的时间，方法是提高限制，以了解通过从属处理可以实现的目标。

来源

2017-07-28 15:49:50

为您的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所表明的那样。您无法在运行脚本中调整限制。

为了更透彻的分析，从从和主 RAM大小为（NNG）

SHOW GLOBAL STATUS 
SHOW GLOBAL VARIABLES 
SHOW INNODB STATUS

来源

2017-08-13 08:26:05

谢谢我会试试这个。我仍然不明白为什么Graph不是100％。它随着流程的运行而上下波动。看起来整个过程会自杀并重新开始，就像它自己重载一样？ –

“监测服务”可以启用定期捕捉系统的“健康检查”，因为它似乎是当你看到尖峰时，在6分钟的周期内。

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

来源

2017-08-15 06:43:19

计算引擎MYSQL服务器CPU奇怪

回答

相关问题