Compute Engine MYSQL Server ЦП странно

Я не мог придумать, как еще назвать эту странную проблему.

У нас есть «рабочий» вычислительный механизм, который является ПОДЧИНЕННЫМ сервером MySQL. Его основная роль состоит в том, чтобы обработать большой набор данных и затем вернуть его на главный сервер. Все обрабатывается с помощью PHP-скрипта.

Теперь обработка данных занимает примерно 4 часа. За это время мы заметили следующую картину процессора.

введите здесь описание изображения

Выше видно, что ЦП на 50% запускается после перезагрузки сервера. Затем примерно через 2 часа он начинает формировать образец стиля ЭКГ на CPu. Примерно каждые 5/6 минут ЦП подскакивает до ~ 48%, а затем падает в течение 5 минут.

У меня вопрос, почему. Объясните, пожалуйста, почему. В идеале мы хотим, чтобы этот сервер максимально увеличивал количество ЦП на 100% (50%, так как у него 2 ядра).

Спецификация сервера: 2 VCPU с 7,5 ГБ памяти.

Как уже упоминалось, было бы здорово, если бы мы могли работать на полном газу. Ниже 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 часа данные там, где я ожидал.


mysql php google-compute-engine google-console-developer
person Steven Church    schedule 28.07.2017    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Изменение innodb_io_capacity = 800 на 1500, вероятно, сократит ваше 4-часовое время, затраченное на обработку, за счет увеличения предела до того, что, как вы знаете, вы можете достичь с помощью своей подчиненной обработки.

person Wilson Hauck    schedule 28.07.2017

arrow_upward
1
arrow_downward

Для указанной среды 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 соединениях потребоваться 16 ГБ + только для того, чтобы эта функция выжила. Маловероятно, что max_allowed_packet на 64M является разумным.

Изменение read_rnd_buffer_size = 4M на SET GLOBAL read_rnd_buffer_size=16384; может иметь большое значение для вашего ведомого устройства, а через 24 часа - для ведущего. Они могут быть разными, но если это значительно сокращает ваши 4 часа на ведомом устройстве, реализуйте оба варианта. Дайте нам знать, что это единственное изменение делает для вас, пожалуйста.

50% -ная загрузка процессора, которую вы видите, - это сценарий, максимально использующий --- одно ядро, которое он может использовать ---. На что недавно указывает PressingOnAlways. Вы не можете настроить ограничение в вашем запущенном скрипте.

Для более тщательного анализа укажите размер ОЗУ ВЕДОМОГО И ГЛАВНОГО (nnG)

SHOW GLOBAL STATUS
SHOW GLOBAL VARIABLES
SHOW INNODB STATUS
person Wilson Hauck    schedule 13.08.2017
comment
Спасибо, я попробую. Я до сих пор не понимаю, почему График не всегда на 100%. Он колеблется вверх и вниз по мере выполнения процесса. Нетронутый, казалось бы, процесс сам себя убивает и запускается заново, как будто сам себя перегружает? - person Steven Church; 14.08.2017

arrow_upward
0
arrow_downward

Процент ЦП измеряется всеми ядрами, поэтому 100% использование ЦП == оба ядра исчерпаны. PHP по умолчанию работает в одном потоке и не использует многоядерность. 50% -ная загрузка процессора, которую вы видите, - это сценарий, максимально использующий одно ядро, которое он может использовать.

Чтобы использовать 100% ЦП, рассмотрите возможность создания 2 сценариев PHP, которые работают с двумя отдельными наборами данных - например, сценарий 1 обрабатывает записи 1-1000000, а сценарий 2 обрабатывает 1000001-2000000.

Другой вариант - переписать сценарий для использования потоков. Возможно, вы захотите полностью изменить язык на что-то более подходящее для потоков, например Golang? Хотя в этом может быть нет необходимости, если основная работа выполняется в mysql.

Другая проблема, с которой вы сталкиваетесь, когда график ниже 50%, может быть связана с ожиданием ввода-вывода. Однако по графику трудно сказать, что у вас может быть узкое место при передаче потока данных, когда ваш процессор не работает и ждет, пока передаются большие биты данных.

Оптимизация использования ЦП - это упражнение по поиску узких мест и их устранению - удачи.

person PressingOnAlways    schedule 28.07.2017
comment
Я так понимаю 50% = 100% 1 ядра. Как сказано :) Спасибо за некоторую информацию о сердцебиении процессора. Может быть IO. Его работающие твердотельные накопители с производительностью около 1500 операций ввода-вывода в секунду. - person Steven Church; 28.07.2017

arrow_upward
0
arrow_downward

«Служба мониторинга» может быть включена для периодического захвата «проверки работоспособности» вашей системы, поскольку при появлении всплесков она, похоже, находится в 6-минутном цикле.

ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК «Com_show_% status», может подтверждать активность такого рода. Разделите счетчики статуса com_show_% на (время работы / 3600), чтобы получить почасовую ставку. 10 раз в час будет каждые 6 минут.

person Wilson Hauck    schedule 15.08.2017