Високе використання процесора MySQL [закрито]


191

Останнім часом мій процесор сервера дуже високий.

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

Після запуску верхньої команди я побачив, що MySQL використовує 160% процесора!

Останнім часом я оптимізував таблиці і перейшов на стійкі з'єднання. Чи може це спричиняє використання MySQL великої кількості процесора?


4
Стійкі зв’язки майже завжди не є правильною справою.
Ясон

я зніму їх зараз і стежу за різницею, тому що я ніколи не пам'ятаю, щоб процесор був вище 2 місяця тому!
Судді

2
Сервери, як правило, мають більше одного ядра. Відсоткове використання процесора обчислюється відносно одного ядра; іншевизначає, що процес, що використовує повністю два ядра, матиме використання процесора 200%. Тут MySQL використовує до 100% одного ядра і 60% іншого ядра. Це не означає, що всі процесори використовуються, швидше за все, у нього ще є щонайменше два безкоштовні процесори.
xaav

Високий процесор майже завжди означає неефективні запити. Зазвичай вони вирішуються за допомогою кращої індексації (особливо "складової") та / або переформулювання запиту.
Рік Джеймс

Відповіді:


265

По-перше, я б сказав, що ви, мабуть, хочете відключити стійкі зв’язки, оскільки вони майже завжди приносять більше шкоди, ніж користі.

По-друге, я б сказав, що ви хочете двічі перевірити своїх користувачів MySQL, просто щоб переконатися, що хтось не може підключатися з віддаленого сервера. Це також є важливою справою безпеки.

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

Ще деякі речі, які ви можете перевірити, - це запустити наступний запит, коли завантаження процесора велике:

SHOW PROCESSLIST;

Це покаже вам будь-які запити, які зараз запущені чи в черзі для запуску, що це за запит і що він робить (ця команда врізає запит, якщо він занадто довгий, ви можете використовувати SHOW FULL PROCESSLIST, щоб побачити повний текст запиту) .

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

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

Також дуже гарна ідея використовувати профілер. Щось ви можете ввімкнути, коли захочете, це покаже вам, які запити працює у вашій програмі, якщо є дублікати запитів, тривалість їх виконання тощо тощо. Прикладом чогось подібного є той, над яким я працював, закликав PHP Profiler, але там багато. Якщо ви використовуєте програмне забезпечення на зразок Drupal, Joomla або Wordpress, ви захочете поцікавитися в межах спільноти, оскільки для них, ймовірно, доступні модулі, які дозволяють отримувати цю інформацію, не потребуючи нічого вручну інтегрувати.


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

та ж проблема, вирішена шляхом індексації таблиць, що сповільнюють процес, дякую Стівену та Джадлінгу
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.
jkincali

167

Оскільки це головна публікація, якщо ви використовуєте Google для завантаження чи завантаження процесора MySQL, я додам додаткову відповідь:

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

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

22
Оскільки оригінальний пост був близько 3 років тому, я сумніваюся, що це причина проблеми оригінального плаката. Але це було причиною моєї проблеми, і врятувало мене саме зараз - тож спасибі! Більше інформації: blog.mozilla.org/it/2012/06/30/…
Russell G

5
Та сама проблема і рішення для мене на Ubuntu 12.04. Кроки для вирішення дещо іншого: сервіс ntp stop && date -s " date" && service ntp start MySQL CPU використання миттєво знизилося з 50 - 100% до 0 - 1%
David Laing

2
Чи можна це виконати лише для впевненості? Я маю на увазі, чи безпечно це запустити, навіть якщо це не причина?
Мухаммед Гелбана

2
1 липня 2015 р. - Я щойно пережив цю дуже високу другу помилку на поточному сервері AWS EC2 під управлінням Amazon Linux. Використовуйте sudo service ntpd stopв цій конфігурації.
Метт ван Андель

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

32

Якщо цей сервер видно зовнішньому світу, варто перевірити, чи є у нього багато запитів на з'єднання із зовнішнім світом (тобто люди, які намагаються прорватися в нього)


1
Не впевнений, чому це призвело до анонімного голосування, враховуючи, що це було причиною в минулому для деяких систем.
Rowland Shaw

2
Я думаю, що голосування проти, тому що наявність MySQL видимого для зовнішнього світу не є хорошою ідеєю.
MikeKulls

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

16
Я ненавиджу, коли хтось просто знижує голоси і йде!
Мухаммед Гельбана

1
+1, тому що це абсолютно законна причина, що MySQL має високе використання процесора, і всім, для кого це відповідь, дійсно потрібна ця інформація!
Кріс Браун
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.