Estuvimos alcanzando los límites superiores de nuestros IOP en los últimos días. Aprovisionamos más IOPS varias veces. 1250 -> 2500 -> 4500. En cada paso vimos rápidamente que estábamos usando todos los IOPS disponibles, ya que alcanzaría el máximo entre lecturas y escrituras.
Finalmente, esta mañana tuvimos otro cliente importante a bordo y nuestra CPU, memoria e IOPS estaban al máximo. Tomé la decisión de proporcionar un tipo de base de datos más grande para mantener el sistema en funcionamiento. Pasamos de db.m5.xlarge a db.m5.2xlarge. También aumentamos los IOP a 8000 con la actualización.
Ahora nuestra CPU está siendo golpeada en comparación y nuestras IOPS son prácticamente 0. La aplicación parece responder pero nuestras colas de tareas son bastante lentas.
Ningún código ha cambiado, solo la base de datos. ¿Qué me estoy perdiendo? ¿RDS no informa correctamente?
Notará los aumentos en IOPS leídos en los últimos 3 días, que coinciden con las disposiciones de IOPS más altas.
Respuesta1
Probablemente tenga una consulta que se cayó por un precipicio. (Gracias por la buena descripción. Aquí está la explicación probable).
Un ejemplo. Digamos que una consulta escanea una tabla de 7 GB (sin un índice útil, etc.) con 70 millones de filas.
Caso 1: RAM = 8 GB; innodb_buffer_pool_size= 6 GB. La consulta elimina todo del caché para finalizar el análisis. Esto requiere una E/S sólida. Todas las demás consultas también se ven afectadas: sus datos también fueron eliminados de la RAM.
Caso 2: RAM = 16 GB; innodb_buffer_pool_size= 12 GB. El primer escaneo carga toda la tabla en caché; Las ejecuciones posteriores de esa consulta no necesitan realizar ninguna E/S. Incluso las otras consultas se ejecutan más rápido debido a la falta de competencia por el caché.
En ambos casos, probablemente haya una gran cantidad de CPU consumida al observar las 70 millones de filas.
Plan A: gastar dinero en tener más RAM, CPU y IOP innecesarios.
Plan B: encuentre esa consulta tan traviesa y pídanos que le ayudemos a optimizarla. Luego puedes volver a una máquina virtual más barata.
Proporcione la consulta y SHOW CREATE TABLElas tablas involucradas. La solución puede ser tan sencilla como añadir un índice compuesto o reformular la consulta.
Respuesta2
La clave aquí era no hacer nada en absoluto. "Mágicamente" nuestra CPU se normalizó a donde esperaba. La buena noticia fue que identifiqué varios puntos débiles en nuestras consultas, algunos bloqueos demasiado entusiastas y MUCHA comprensión sobre cómo ajustar InnoDB/RDS/MySQL.
Quizás RDS estaba optimizando lentamente los índices o algo que no entiendo del todo, pero ahora nuestra latencia es sorprendente, el rendimiento y el uso son exactamente los que esperaría con 4 núcleos más y el doble de memoria.
