Процесс MySQL, занимающий 150-400% ЦП
Мое программное обеспечение выполняет множество запросов MySQL к моему серверу, и в прошлом у меня никогда не было проблем с ним, но совсем недавно ничего не загружалось, ни веб-страницы, ни SQL не выполнялись, ничего. Мне удалось подключиться к WHM для моего сервера и убить процесс, только чтобы увидеть, как он снова вырос до 300%. Ничего из того, что я смог сделать, не привело к его снижению. Какой информацией мне нужно поделиться, чтобы получить помощь в этом вопросе? Я не системный администратор, и у меня нет ни одного ресурса для него. Обычно я не просил бы о помощи и просто оптимизировал все свои запросы для чего-то вроде этого, поскольку это не было проблемой в течение последних 3 месяцев, но внезапно стало проблемой из ниоткуда, по крайней мере, я этого не заметил. В этот момент моя программа сообщает, что одна из таблиц моей базы данных вышла из строя и нуждается в ремонте ... Что я могу сделать? Заранее благодарю за любую помощь...
Я уже рассматривал оптимизацию, но я надеялся на быстрое решение для реализации, так как у меня есть клиенты, которые ждут, и тогда я могу потратить несколько дней на оптимизацию моего SQL, который, как я уже сказал, раньше не имел никаких проблем. Я смущен этим.
Также я не уверен, помогает ли это, но отслеживание процесса в WHM печатает это повторно и ничего больше:
fcntl(16, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(16, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(16, {sa_family=AF_LOCAL, NULL}, [2]) = 35
fcntl(16, F_SETFL, O_RDWR) = 0
setsockopt(35, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x13298a4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x13298a0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1327240, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=14, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}])
/etc/my.conf
innodb_file_per_table=1
default-storage-engine=MyISAM
performance-schema=0
max_allowed_packet=268435456
open_files_limit=10000
Это все, что мне доступно по файлу my.conf. Журнал ошибок не существует в /var/log, поэтому мне нечего сказать по этому поводу ...
Версия SQL:
[Server] # mysql -V
mysql Ver 14.14 Distrib 5.6.41, for Linux (x86_64) using EditLine wrapper
У меня есть дополнительный вопрос или дополнение к этому. Я не знаю, имеет ли это большое значение, но, скажем, мой код работает с использованием 30% ЦП в процессе mysql, я могу фактически отключить код, и использование ЦП процессом mysql не изменится. Что это значит?
Обновлено: (все они истекают в течение недели с 12/09/2018)
Содержимое файла my.cnf, которое я перечислил, - это все, что там было. Ничего больше. Я получу команду top и iostat -xm 5 3, когда снова запущу программное обеспечение на полной скорости, чтобы увидеть результаты.
Проверьте журналы MySQL, возможно, как говорит ваша программа, у вас разбилась таблица
В порядке. Мой серверный хостинг проходит через godaddy, мне не на что быстро переходить. У вас есть какие-нибудь рекомендации? Вся база данных составляет около 14 ГБ с несколькими таблицами с несколькими миллионами записей, которые я создал. Полагаю, я могу вызвать им и надеюсь, что кто-нибудь, кто знает, что они делают, ответит на звонок. Позвольте мне получить журнал ошибок и настройки my.cnf. Последний раз смотрел, хотя в нем было всего 4 или 5 настроек. Стол, который у меня был, разбился, но я восстановил его через PhpMyAdmin
Включить журнал медленных запросов, это таблицы MyISAM или Innodb? Какая версия MySQL (SELECT VERSION())?
Хорошо, я включу журнал медленных запросов, таблицы - это MyISAM, как показано в my.conf, и версия также указана сейчас. 5.6.41
Журнал медленных запросов включен. Я могу вставить сюда вывод?
Поскольку GoDaddy предоставляет хостинг; их техническая поддержка уровня 2 должна быть в состоянии предоставить вам поддержку в отношении диагностики и возможного решения проблемы, особенно если она связана с оборудованием, если только она не вызвана приложением. Журнал медленных запросов будет определять только аномальные запросы, выполнение которых занимает много времени, но не обязательно коррелирует с загрузкой ЦП. Найдите в каталоге /var/lib/mysql или SELECT @@log_error файлы журнала. Вы должны увидеть файл mysql-error.log, в котором будет отображаться информация о запуске службы и любые ошибки, в зависимости от вашего уровня log_error_verbosity.
Я точно. Я постараюсь перезвонить им через несколько минут. Я позволил журналу медленных запросов работать всю ночь с моим кодом, и он ничего не добавил в журнал. Я только что проверил журнал ошибок, который почему-то был под другим именем. Ничего необычного не кажется. Есть немного для неразрешенного IP-адреса, некоторые для восстановления таблицы и иного перезапуска службы MySQL, а также моего сервера. (Единственный способ, который я нашел, чтобы очистить процессор). Ничего очевидного.
Я не знаю, имеет ли это большое значение, но, скажем, мой код работает с использованием 30% ЦП в процессе mysql, я могу фактически отключить код, и использование ЦП процессом mysql не изменится. Что это значит? Кроме того, даже если я буду очень осторожен с этим, загрузка ЦП по какой-то причине будет медленно расти. Скажем, это 30%, и я позволил всему работать, он будет на 90%, затем 150% к этому моменту таблица выйдет из строя, но. Раньше, когда я писал этот пост, я запустил свое программное обеспечение, и загрузка ЦП была увеличена до 350%, но с тех пор я был осторожен. Может быть, от незакрытых подключений?
Это только означает, что проблема не проявляется, если mysql не взаимодействует так, как работает приложение. Например, читает и / или записывает в базу данных и / или определенные таблицы или путем вызова определенных процедур / триггеров. Например, вызов функции MySQL выполняется как бесконечный цикл. Если в журнале ошибок ничего не выделяется, а ваш уровень детализации равен 3, я бы посмотрел на проблемы уровня приложения, такие как бесконечные циклы. PHP и MySQL имеют тайм-ауты соединения по умолчанию, которые вы не указали, когда вы изменили, и PHP закрывает соединения после завершения каждого запроса.
Точно. В течение последних нескольких часов процент использования моего процессора по непонятным причинам довольно сильно колебался. Мое приложение написано на Python и использует библиотеку mysql.connector. Кажется, не существует бесконечных циклов, как они представлялись бы в приложении, которое я мог бы себе представить. Он определенно зацикливается, как двигатель, но только до остановки. Последние несколько часов я работал над устранением ненужных (лишних) соединений, а также перечислял свои запросы для создания индексов в БД. Не знаю, что еще делать, пока не найду другое решение.
Ответы 1
Скорость в секунду = количество запросов в секунду. Предложения для рассмотрения на основе отчета Linux ulimit -a.
ulimit -n 16384 to raise Open Files limit from 1024 to support your activities.
Чтобы это сохранялось при выключении / перезагрузке Linux, просмотрите этот URL.
https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
Ваши особенности могут немного отличаться в зависимости от версии Linux.
Предложения для вашего раздела my.cnf [mysqld]
innodb_lru_scan_depth=100 # from 1024 to reduce CPU busy every second. 93% savings for this one function.
thread_cache_size=32 # from 9 for thread breathing room and growth.
innodb_io_capacity=1800 # from 200 to take advantage of your HDD IOPS capacity
key_cache_age_threshold=7200 # from 300 seconds to reduce key_reads RPS of 16
query_cache_size=0 # from 1M to conserve RAM - QC is OFF and not used
query_cache_limit=0 # from 1M to conserve RAM - QC is OFF and not used
key_buffer_size=128M # from 8M which had NO free space at the end of your work day
Дополнительные предложения см. В моем профиле, в профиле сети для получения контактной информации.
@ Pixelknight1398 У вас было время применить 7 предложений, опубликованных 11 декабря 2018 г.? Каково ваше текущее положение? Счастливых праздников.
Лучше всего восстановить резервную копию вашей базы данных на отдельном сервере и использовать ее до тех пор, пока вы не определите проблему на сервере. Дополнительная загрузка ЦП более чем вероятна из-за попытки MySQL восстановить данные из двоичного журнала или неудачных попыток чтения / записи. Но если не знать больше, это похоже на проблему, связанную с оборудованием, такую как неисправный сектор жесткого диска, отказ SSD или оперативной памяти, которые привели к повреждению данных таблицы. Вам нужно будет поделиться информацией из вашего журнала ошибок mysql, ваших настроек
my.cnf(удаление конфиденциальной информации, такой как имя пользователя / пароль).