Lottando per il debug dell'utilizzo elevato della CPU sull'istanza MySQL di Amazon RDS

Stiamo eseguendo un server MySQL RDS m1.xlarge e riscontriamo alcuni problemi con un elevato utilizzo della CPU. Abbiamo avuto alcuni problemi un paio di settimane fa con l'utilizzo della CPU che ha raggiunto il 100% su un'istanza di grandi dimensioni. Quando abbiamo aggiornato le dimensioni per ingrandirle che hanno stabilizzato le cose per un po ', ma l'utilizzo della CPU è gradualmente aumentato di nuovo.

Nell'ultima settimana circa l'utilizzo della CPU è stato negli anni '90, ieri ha raggiunto il 100% o giù di lì, il che ha bloccato il nostro sito di produzione. Dopo aver riavviato il server db, in poche ore l'utilizzo della CPU è risalito agli stessi livelli.

Ho eseguito show processlist sul server mysql e ho monitorato lo stesso tramite l'amministratore MySQL. Non sembra esserci alcuna query particolarmente lunga o un elevato volume di query. Ci sono un paio di processi che si trovano nello stato di sospensione per lungo tempo ... si tratta di demoni dei lavoratori isolati in esecuzione al di fuori della nostra app principale che comunicano con il database. Ho copiato nell'output dell'elenco processi di seguito con i nomi dei server modificati per dare una descrizione di cosa sono:

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

Dovrei anche dire che il traffico sul sito è estremamente basso durante questo periodo, rispetto alle normali ore di punta, circa il 10% del carico che vediamo nelle ore di punta.

Abbiamo anche un nuovo monitoraggio delle reliquie che ci mostra quali sono le chiamate al database delle app che richiedono più tempo. Ci mostra che una chiamata particolare che rappresenta il 99% delle volte che la nostra app trascorre nel db è una semplice ricerca per query id come questa:

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

(non è lo stesso delle query in esecuzione nell'elenco di processi sopra)

Questa operazione è diventata più lenta nell'ultima settimana circa, con la deviazione standard tra le richieste di tempo che aumenta e anche la quantità massima di tempo che viene misurata in termini di secondi. Penso che questo sia solo il risultato dei problemi di utilizzo della CPU piuttosto che una causa.

Questa tabella ha circa 80.000 righe, quindi non è enorme. Si prevede che la maggior parte del tempo delle app nel database sia dedicato alla ricerca di record in questa tabella, la funzionalità principale dell'app si basa su questo. Ho eseguito una query simile dal mio server delle applicazioni al database di produzione alcune volte, mentre l'utilizzo della CPU rimane circa il 100% e risponde entro 1 o 2 ms.

Sulla base di tutto quanto sopra, non siamo sicuri su come procedere con il nostro debug. Mi chiedevo solo se qualcuno avesse qualche idea di che tipo di cose potrebbe essere una causa alla radice e come indagarle? L'accesso al server sottostante che esegue il nostro server db è limitato poiché si tratta di un'istanza Amazon RDS.

Gestiti per risolvere questo, questi sono i passaggi che ho seguito:

In primo luogo, ho contattato il team Amazon RDS pubblicando sul loro forum di discussione, hanno confermato che era il processo mysqld che occupava tutta questa CPU - questo ha eliminato un errore di configurazione con qualcos'altro in esecuzione sul server fisico

In secondo luogo ho rintracciato l'origine delle query in esecuzione:

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

Inizialmente l'ho trascurato come causa, perché nessuna di queste query sembrava impiegare particolarmente tempo quando ho monitorato l'output dello showlist dello spettacolo. Dopo aver esaurito altri viali, ho deciso che valeva la pena seguirlo ... e sono contento di averlo fatto.

Come puoi vedere nell'output dello show list del processo, queste query provenivano da un server di utlility, che esegue alcuni processi di utilità tattica che esistono al di fuori del nostro codice principale dell'applicazione. Questo è il motivo per cui non si sono mostrati lenti o hanno causato problemi nel nostro nuovo monitoraggio delle reliquie, perché il nuovo agente reliquie è installato solo sul nostro server delle app principale.

Seguendo vagamente questa guida:

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

Sono stato in grado di tracciare queste query su un processo in esecuzione specifico sulla nostra casella del server di utilità. Questo era un po 'di codice ruby ​​che scorreva in modo molto inefficiente attraverso circa 70.000 record, controllando alcuni valori di campo e usando quelli per decidere se fosse necessario creare un nuovo record in "mytable". Dopo aver fatto alcune analisi che sono stato in grado di determinare, il processo non era più necessario e quindi poteva essere ucciso.

Qualcosa che stava peggiorando le cose, sembravano esserci 6 istanze di questo stesso processo in esecuzione contemporaneamente a causa del modo in cui il lavoro cron era configurato e quanto tempo impiegava ciascuna! Ho interrotto questi processi e incredibilmente il nostro utilizzo della CPU è sceso dal 100% circa al 5% circa!