MySQL высокая загрузка ЦП [закрыто]

191

Закрыто. Этот вопрос не по теме . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он соответствовал теме переполнения стека.

Закрыто 8 лет назад .

В последнее время мой серверный процессор был очень высоким.

Загрузка процессора в среднем составляет 13,91 (1 мин), 11,72 (5 мин), 8,01 (15 мин), и трафик на моем сайте был незначительным.

После запуска команды top, я увидел, что MySQL использует 160% CPU!

Недавно я оптимизировал таблицы и переключился на постоянные соединения. Может ли это быть причиной того, что MySQL использует большое количество процессоров?

mysql cpu-usage

— Juddling
источник

Постоянные соединения - почти всегда неправильная вещь.

— Джейсон

Я сниму их сейчас и наблюдаю за разницей, потому что я никогда не помню, чтобы процессор был выше 2 месяц назад!

— судить

Серверы, как правило, имеют более одного ядра. Процент использования ЦП рассчитывается относительно одного ядра, другими словами, процесс, использующий два ядра полностью, будет использовать ЦП 200%. Здесь MySQL использует 100% одного ядра и 60% другого ядра. Это не означает, что все процессоры израсходованы, скорее всего, у него все еще есть как минимум два свободных процессора.

— xaav

Высокая загрузка процессора почти всегда означает неэффективные запросы. Такие проблемы обычно решаются путем лучшей индексации (особенно «составной») и / или переформулирования запроса.

— Рик Джеймс

Ответы:

265

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

Во-вторых, я бы сказал, что вы хотите дважды проверить пользователей MySQL, просто чтобы убедиться, что никто не может подключиться с удаленного сервера. Это также важная вещь для проверки безопасности.

В-третьих, я бы сказал, что вы хотите включить MySQL Slow Query Log, чтобы следить за любыми запросами, которые занимают много времени, и использовать его, чтобы убедиться, что у вас нет запросов, блокирующих таблицы ключей слишком долго.

Некоторые другие вещи, которые вы можете проверить, это выполнить следующий запрос при высокой загрузке процессора:

SHOW PROCESSLIST;

Это покажет вам любые запросы, которые в данный момент выполняются или находятся в очереди для выполнения, что это за запрос и что он делает (эта команда будет обрезать запрос, если он слишком длинный, вы можете использовать SHOW FULL PROCESSLIST, чтобы увидеть полный текст запроса) ,

Вы также хотите , чтобы держать глаза на такие вещи , как ваш размер буфера, кэш - таблицы , кэш запросов и innodb_buffer_pool_size (если вы используете InnoDB таблиц) , как все эти выделения памяти могут иметь влияние на производительность запросов , которые могут привести к MySQL к кушай процессор.

Вы также, вероятно, захотите прочитать следующие материалы, так как они содержат полезную информацию.

Также очень хорошая идея использовать профилировщик. То, что вы можете включить, когда захотите, покажет вам, какие запросы выполняет ваше приложение, есть ли дублирующие запросы, сколько времени они занимают, и т. Д., И т. Д. Примером чего-то подобного является тот, над которым я работал PHP Profiler, но есть много там. Если вы используете какое-либо программное обеспечение, такое как Drupal, Joomla или Wordpress, вам нужно будет поинтересоваться в сообществе, поскольку, вероятно, для них доступны модули, которые позволяют вам получать эту информацию без необходимости что-либо интегрировать вручную.

— Стивен Суровец
источник

Большое спасибо за это, я удалил постоянные соединения, а затем настроил медленный журнал запросов. Я прочитал журнал, и большинство запросов поступило из двух таблиц, и таблицы не были проиндексированы должным образом! прошло всего около 10 минут, но вот результат: загрузка процессора в среднем составляет 0,48 (1 мин), 0,95 (5 мин), 2,42 (15 мин), большое спасибо

— Juddling

Та же проблема, решена путем индексирования таблицы , которые замедляют процесс, спасибо Стивену и Juddling

— gabrielem

@ Juddling Не могли бы вы уточнить, как индексировать таблицу, пожалуйста? Возможно какая-то ссылка? Я знаю, что это было давно, но я действительно новичок в этом деле. Извините за нубистский вопрос

— JayVDiyk

Регистрация медленных запросов помогла мне найти конкретную проблему высокой загрузки ЦП. В моем случае это был плагин Wordpress (ultimate-tag-cloud-widget), который делал чудовищный запрос с каждым попаданием, чтобы показать популярные теги. Это отличный плагин, но его нужно улучшить, добавив кеширование (в итоге я настроил его, чтобы решить мою проблему).

— Jkincali

Другая вещь, которая помогла другой проблеме, была модификация параметра innodb_buffer_pool_size, упомянутого выше. Пытаясь найти причину высокой загрузки ЦП, я где-то читал, что innodb_buffer_pool_size должен иметь размер не менее размера файла ibdata1, который находится в / var / lib / mysql. Кажется, что InnoDB работает намного эффективнее, когда он может находиться в памяти. Это может быть трудно сделать в некоторых ситуациях, потому что ibdata1 может быть огромным! Также было предложено где-то убедиться, что innodb_log_buffer_size составляет 25% от размера innodb_buffer_pool_size.

— Джкинкали

167

Поскольку это верхний пост, если вы пользуетесь Google для MySQL высокой загрузкой процессора или загрузкой, я добавлю дополнительный ответ:

1 июля 2012 года была добавлена дополнительная секунда к текущему времени UTC, чтобы компенсировать замедление вращения Земли из-за приливов. При запуске ntp (или ntpd) эта секунда добавлялась к часам вашего компьютера / сервера. MySQLd, похоже, не нравится эта дополнительная секунда в некоторых ОС, и приводит к высокой загрузке процессора. Быстрое исправление (от имени root):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start

— RedPixel
источник

Поскольку оригинальный пост был около 3 лет назад, я сомневаюсь, что это является причиной проблемы оригинального постера. Но это стало причиной моей проблемы и спасло меня только сейчас - так что спасибо! Дополнительная информация: blog.mozilla.org/it/2012/06/30/…

— Рассел Г

Та же проблема и решение для меня на Ubuntu 12.04. Действия для решения немного отличаются: служба ntp stop && date -s " date" && service ntp start Использование ЦП MySQL мгновенно упало с 50 - 100% до 0 - 1%

— Дэвид Лэйнг

Может ли это быть выполнено только для уверенности? Я имею в виду, безопасно ли запустить его, даже если это не причина?

— Мухаммед Гелбана

1 июля 2015 г. - Я только что столкнулся с этой очень большой ошибкой на текущем сервере AWS EC2 под управлением Amazon Linux. Используйте sudo service ntpd stopна этой конфигурации.

— Мэтт ван Андел

+1 за это решение. Мой MySQL работал без причины на уровне 50-60% в течение нескольких месяцев, после применения этого решения он снизился до всего 0,0-0,3%, как и предполагалось. Большое спасибо.

— Зеешан

Если этот сервер виден внешнему миру, стоит проверить, есть ли у него множество запросов на подключение из внешнего мира (то есть людей, пытающихся проникнуть на него)

— Роуланд Шоу
источник

Не уверен, почему это привлекло анонимное снижение, учитывая, что это было причиной в прошлом для некоторых систем.

— Роуланд Шоу

Я думаю, что отрицательный результат заключается в том, что MySQL, видимый для внешнего мира, не очень хорошая идея.

— MikeKulls

@MikeKulls Нет, это не очень хорошая идея, так как она станет целью для многих людей, чтобы попытаться получить доступ, что приведет к высокой загрузке процессора - отсюда мой ответ в качестве одной из возможных причин.

— Роуланд Шоу,

Я ненавижу, когда кто-то просто понижает голос и уходит!

— Мухаммед Гелбана

+1, потому что это абсолютно законная причина для высокой загрузки ЦПУ MySQL, и любой, для кого это ответ, действительно нуждается в этой информации!

— Крис Браун