Amazon RDS MySQL örneğinde yüksek CPU kullanımında hata ayıklama mücadelesi

Bir m1.xlarge MySQL RDS sunucusu çalıştırıyoruz ve yüksek CPU kullanımıyla ilgili bazı sorunlar yaşıyoruz. Birkaç hafta önce bazı durumlarda CPU kullanımı büyük bir oranda% 100'e ulaştı. Boyutları yükselttikten sonra, bir süre işleri sabitleyen xlarge seviyesine yükseldik, ancak CPU kullanımı yavaş yavaş tekrar arttı.

Geçtiğimiz hafta boyunca CPU kullanımı 90'lı yılların en yüksek seviyesindeydi ve dün% 100'e ulaştı ve bu da üretim alanımızı durduracaktı. Db sunucusunu yeniden başlattıktan sonra, birkaç saat içinde CPU kullanımı aynı seviyelere çıktı.

MySQL sunucusundan mysql sunucusunda show processlist'i çalıştırdım ve aynı şeyi izliyorum. Özellikle uzun süredir devam eden sorgular veya yüksek miktarda sorgu olmadığı görülüyor. Uzun süre uyku durumunda olan birkaç işlem var ... bunlar, veritabanımızla iletişim kuran ana uygulamamızın dışında çalışan yalıtılmış işçilerdir. Aşağıdaki işlem listesi çıktısında kopyaladıklarını, sunucu adları değiştirildiklerinde, ne olduklarının açıklamasını verdim:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 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 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

Ayrıca, bu dönemde, normal yoğun saatlere göre yoğun saatlerde gördüğümüz yükün yaklaşık% 10'una oranla sitedeki trafiğin çok düşük olduğunu söylemeliyim.

Ayrıca, en fazla zaman alan uygulama veritabanı çağrısının ne olduğunu bize gösteren yeni bir kalıntı izlemeye sahibiz. Bu, uygulamanın db'de geçirdiği zamanın% 99'unu oluşturan belirli bir çağrının, bunun gibi bir kimlik sorgusuna göre basit bir keşif olduğunu gösteriyor:

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

(yukarıdaki işlem listesinde çalışan sorgularla tamamen aynı değildir)

Bu işlem, geçen hafta ya da öylesine yavaşladı, zaman talepleri arasındaki standart sapma artıyor ve aynı zamanda saniye cinsinden ölçülen maksimum zaman miktarı. Bunun sadece bir sebep yerine CPU kullanım problemlerinin bir sonucu olduğunu düşünüyorum.

Bu tablonun yaklaşık 80.000 satırı var bu yüzden çok büyük değil. Veritabanındaki uygulama zamanlarının çoğunun bu tablodaki kayıtları aramak için harcanması beklenir, uygulamanın temel işlevselliği buna dayanır. İşlemci kullanımım% 100 civarında kalırken uygulama sunucumdan üretim veritabanına birkaç kez benzer bir sorgu çalıştırdım ve 1 veya 2 ms içinde yanıt veriyor.

Yukarıdakilere dayanarak, hata ayıklama işlemimize nasıl devam edeceğimizden emin değiliz. Birisinin herhangi bir fikrinin olup olmadığını, ne gibi şeylerin temel bir sebep olabileceğini ve bunların nasıl araştırılabileceğini merak ettim. Db sunucumuzu çalıştıran sunucuya erişim, bir Amazon RDS örneğinden beri sınırlıdır.

Bunu çözmeyi başardım, takip ettiğim adımlar:

Öncelikle, Amazon RDS ekibiyle tartışma forumlarına yazarak bağlantıya geçtim, tüm bu CPU'ları alarak mysqld işlemi olduğunu doğruladılar - bu fiziksel sunucuda çalışan başka bir şeyle bir yapılandırma hatasını ortadan kaldırdı.

İkincisi, çalışan sorguların kaynağını buldum:

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

İlk başta bunun nedeni olarak görmezden geldim, çünkü bu sorguların hiçbiri, gösteri işlem listesi çıktısını izlediğimde çok uzun sürmüyor gibi görünüyordu. Diğer caddeleri yorduktan sonra takip etmeye değeceğine karar verdim .... ve yaptığım için mutluyum.

Show işlem listesi çıktısında görebileceğiniz gibi, bu sorgular ana uygulama kodumuzun dışında bulunan bazı taktik yardımcı işlerini yürüten bir yardımcı sunucudan geliyordu. Bu nedenle, yeni kalıntı izlememizde yavaş görünmüyor ya da sorun yaratmıyorlardı, çünkü yeni kalıntı ajan sadece ana uygulama sunucumuza kuruluyor.

Bu kılavuzu yavaşça takip edin:

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

Bu sorguları yardımcı program kutumuzdaki belirli bir çalışan işlemle takip edebildim. Bu, yaklaşık 70.000 kayıt boyunca yinelenen, bazı alan değerlerini kontrol eden ve bunları 'mytable' içinde yeni bir kayıt oluşturmaya ihtiyaç duyup duymadığına karar vermek için kullananları verimsiz biçimde gösteren bir ruby ​​kodudur. Bazı analizler yaptıktan sonra belirleyebildiğim için, bu işlem artık gerekli değildi, böylece öldürülebilirdi.

İşleri daha da kötüleştiren bir şey, cron işinin yapılandırılma biçimi ve her birinin ne kadar sürdüğü nedeniyle aynı anda 6 işlemin aynı anda gerçekleştiği görülüyordu! Bu süreçleri öldürdüm ve inanılmaz derecede CPU kullanımımız% 100'den% 5'e düştü!