Бореться за налагодження високого використання процесора в екземплярі Amazon RDS MySQL

Ми запускаємо сервер RDS m1.xlarge MySQL і маємо деякі проблеми з високим рівнем використання процесора. Кілька тижнів тому у нас виникли деякі проблеми з використанням процесора, досягнувши 100% у великому випадку. Коли ми модернізували розмір до більшого розміру, який стабілізував речі на деякий час, але використання процесора поступово знову повстало.

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

Я запустив показ процесорних списків на сервері mysql і моніторив його за допомогою адміністратора MySQL. Здається, немає також особливо тривалих запитів або великого обсягу запитів. Існує пара процесів, що довго лежать у стані сну ... це окремі демони робітників, що працюють поза нашим основним додатком, які спілкуються з базою даних. Я скопіював у вихідний список списку процесів із зміненими іменами серверів, щоб дати характеристику того, що вони:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

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

Також у нас є новий реліктовий моніторинг, який показує, які найбільш затребувані дзвінки до бази даних додатків. Це показує нам, що один конкретний дзвінок, який займає 99% часу, який наша програма проводить у db, - це проста знахідка за запитом id таким чином:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

(не зовсім те саме, що запити, які виконувались у наведеному вище списку процесів)

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

Ця таблиця містить близько 80 000 рядків, тому не величезна. Очікується, що більша частина часу програм у базі даних витрачається на пошук записів у цій таблиці, основна функціональність програми базується на цьому. Я декілька разів запускав подібний запит від свого сервера додатків до виробничої бази даних, тоді як використання процесора залишається близько 100%, і він відповідає протягом 1 або 2 мс.

Виходячи з усього вищесказаного, ми не впевнені, як діяти з налагодженням. Просто цікаво, чи хтось мав ідеї, які речі можуть бути першопричиною і як їх розслідувати? Доступ до базового сервера, на якому працює наш db-сервер, обмежений, оскільки його екземпляр Amazon RDS є обмеженим.

Це вдалося вирішити, це наступні кроки:

По-перше, я зв’язався з командою Amazon RDS, розмістивши їх на дискусійному форумі, вони підтвердили, що це був mysqld процес, що займає весь цей процесор - це усунуло помилки конфігурації з чимось іншим, що працює на фізичному сервері

По-друге, я відстежував джерело запущених запитів:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 

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

Як ви бачите у виведенні списку процесорів шоу, ці запити надходили від сервера utlility, який виконує деякі тактичні завдання утиліти, які існують поза нашим основним кодом програми. Ось чому вони не відображалися настільки повільно або не викликали проблем у нашому новому моніторингу реліквій, оскільки новий реліктовий агент встановлений лише на нашому головному сервері додатків.

Потрібно слідувати цьому посібнику:

http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/

Мені вдалося простежити ці запити до конкретного запущеного процесу на нашому серверному сервісі утиліти. Це було трохи рубінового коду, який дуже неефективно повторювався через близько 70 000 записів, перевіряючи деякі значення поля та використовуючи ті, щоб вирішити, чи потрібно створювати нову запис у "mytable". Зробивши деякий аналіз, який я зміг визначити, процес уже не потрібен, тому його можна було вбити.

Щось щось погіршило, здавалося, що за один раз 6 процесів цього самого процесу відбувається завдяки тому, як налаштовано роботу cron та скільки часу займає кожен! Я знищив ці процеси, і неймовірно наше використання процесора впало з приблизно 100% до приблизно 5%!