Berjuang untuk men-debug penggunaan CPU yang tinggi di Amazon MySQL RDS misalnya

Kami menjalankan server MySQL RDS m1.xlarge dan mengalami beberapa masalah dengan penggunaan CPU yang tinggi. Kami memiliki beberapa masalah beberapa minggu yang lalu dengan pemanfaatan CPU mencapai 100% pada contoh besar. Ketika kami meningkatkan ukuran ke xlarge hal-hal yang stabil untuk sementara waktu tetapi penggunaan CPU secara bertahap merangkak naik.

Untuk minggu terakhir ini, penggunaan CPU telah mencapai angka 90an, mencapai 100% atau sekitar kemarin secara konsisten, yang membuat lokasi produksi kami terhenti. Setelah me-reboot server db, dalam beberapa jam penggunaan CPU naik kembali ke level yang sama.

Saya sudah menjalankan show processlist di server mysql, dan telah memantau hal yang sama melalui admin MySQL. Tampaknya tidak ada kueri yang berjalan lama atau sejumlah besar kueri. Ada beberapa proses berbaring dalam keadaan tidur untuk waktu yang lama ... ini adalah dasmon pekerja terisolasi yang berjalan di luar aplikasi utama kami yang berkomunikasi dengan database. Saya telah menyalin dalam output daftar proses di bawah ini dengan nama server diubah untuk memberikan deskripsi tentang apa itu:

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

Saya juga harus mengatakan lalu lintas di situs sangat rendah selama periode ini, relatif terhadap jam sibuk normal, sekitar 10% dari beban yang kita lihat pada waktu puncak.

Kami juga memiliki pemantauan peninggalan baru yang menunjukkan kepada kami panggilan database aplikasi apa yang paling memakan waktu. Ini menunjukkan kepada kita bahwa satu panggilan khusus yang menyumbang 99% dari waktu yang dihabiskan aplikasi kita di db adalah penemuan sederhana dengan permintaan id seperti ini:

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

(tidak persis sama dengan kueri yang berjalan di daftar proses di atas)

Operasi ini menjadi lebih lambat selama seminggu terakhir ini, dengan standar deviasi antara permintaan waktu meningkat, dan juga jumlah waktu maksimum yang dibutuhkan diukur dalam hitungan detik. Saya pikir ini hanya hasil dari masalah pemanfaatan CPU daripada penyebabnya.

Tabel ini memiliki sekitar 80.000 baris sehingga tidak besar. Diharapkan bahwa sebagian besar waktu aplikasi dalam database dihabiskan untuk mencari catatan dalam tabel ini, fungsi utama aplikasi ini didasarkan pada hal ini. Saya sendiri telah menjalankan permintaan serupa dari server aplikasi saya ke basis data produksi, sementara penggunaan CPU tetap sekitar 100%, dan ia merespons dalam 1 atau 2 ms.

Berdasarkan semua hal di atas, kami tidak yakin bagaimana melanjutkan dengan debugging kami. Hanya ingin tahu apakah ada yang punya ide hal-hal apa yang mungkin menjadi akar penyebab dan bagaimana menyelidiki ini? Akses ke server dasar yang menjalankan server db kami terbatas karena merupakan instance Amazon RDS.

Berhasil menyelesaikan ini, ini adalah langkah-langkah yang saya ikuti:

Pertama, saya menghubungi tim Amazon RDS dengan memposting di forum diskusi mereka, mereka mengkonfirmasi itu adalah proses mysqld mengambil semua CPU ini - ini menghilangkan kesalahan konfigurasi dengan sesuatu yang lain berjalan di server fisik

Kedua saya melacak sumber kueri yang berjalan:

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

Saya awalnya mengabaikan ini sebagai penyebabnya, karena tidak satu pun dari pertanyaan ini tampaknya memakan waktu lama ketika saya memantau output daftar proses tampilkan. Setelah melelahkan jalan lain, saya memutuskan mungkin ada baiknya menindaklanjuti .... dan saya senang saya lakukan.

Seperti yang dapat Anda lihat di output daftar proses tampilkan, pertanyaan ini berasal dari server utlility, yang menjalankan beberapa pekerjaan utilitas taktis yang ada di luar kode aplikasi utama kami. Inilah sebabnya mengapa mereka tidak muncul sebagai lambat atau menyebabkan masalah dalam pemantauan peninggalan baru kami, karena agen peninggalan baru hanya diinstal pada server aplikasi utama kami.

Secara longgar mengikuti panduan ini:

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

Saya bisa melacak pertanyaan ini ke proses menjalankan tertentu pada kotak server utilitas kami. Ini adalah sedikit kode ruby ​​yang sangat tidak efisien mengulangi sekitar 70.000 catatan, memeriksa beberapa nilai bidang dan menggunakan mereka untuk memutuskan apakah perlu membuat catatan baru di 'mytable.' Setelah melakukan beberapa analisis yang saya dapat menentukan, proses tidak lagi diperlukan sehingga bisa dibunuh.

Sesuatu yang memperburuk masalah, tampaknya ada 6 contoh dari proses yang sama ini berjalan pada satu waktu karena cara pekerjaan cron dikonfigurasi dan berapa lama masing-masing memakan waktu! Saya membunuh semua proses ini, dan hebatnya penggunaan CPU kami turun dari sekitar 100% menjadi sekitar 5%!