Optimizar la base de datos PERCONA MYSQL INNODB 3.2TB

Question

(Antes de que me llame idiota o comience a reírse, recuerde que es un trato real de mi lado y no puedo cancelar esta tarea, ya que es parte de un proyecto más grande)

Tengo un servidor de base de datos que es un tamaño más grande y se está ejecutando en un pequeño servidor loco, es decir. RAM de 32 GB, 24 núcleos. Durante el fin de semana, vamos a agregar 18 GB de RAM a la máquina para que ITSY BITSY sea más capaz (¡la carga del servidor durante el día salta hasta el promedio de 80!) Hasta que ordenemos problemas de rendimiento con la aplicación utilizando esta base de datos. < / p>

Sospecho que la carga es causada por DB está intercambiando debido a la falta de RAM libre (aproximadamente 5 GB siempre en swap).

Esta base de datos tiene múltiples tablas pequeñas e ish y una tabla enorme que está recibiendo datos GPS e IO a la velocidad alrededor de 350,000 registros / h y esta tabla se divide por una partición / mes.

MySqlTuner sugiere correr optimizar la tabla en todas las tablas, pero he leído que hacerlo en las tablas innodb es inútil y también tomaría largas horas.

Aquí hay un snip de la salida del script:

General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
  query_cache_limit (> 16M, or use smaller result sets)
  join_buffer_size (> 2.0M, or always use indexes with joins)
  tmp_table_size (> 16M)
  max_heap_table_size (> 16M)
  table_cache (> 4096)
  innodb_buffer_pool_size (>= 1726G)

¿Debo confiar ciegamente en él o hay otra forma de hacer esto?

Sé que lo primero es reconfigurar el DB después de la actualización, ¿de qué otra cosa debo tener en cuenta y qué debería intentarlo? El tiempo de inactividad debe ser lo más corto posible, así que realmente no quiero ejecutar una consulta que se ejecutara durante 5 horas.

Answer 1

Olvídate de MySqlTuner y verifique el consejo humano . Esta herramienta le informa recomendaciones generales que pueden ser inútiles e incluso hirientes en algunos casos. Optimizar la tabla probablemente será inútil, pero bloquea sus mesas para escribir. Un consultor puede ahorrarle tiempo y dinero a largo plazo.

El intercambio debe ser un NO-IR para MySQL . Asegúrese de ajustar su innodb_buffer_pool_size para maximizar el uso de la memoria sin intercambiar. Asegúrese de comprender que puede haber otras cosas usando la memoria: Caché de sistema de archivos , necesario para registrar y otras operaciones, y per-cliente usó la memoria, como el búfer de unión y los buffers de clasificación . Todos juntos deben ser menos que la memoria física disponible, ya que MYSQL / INNODB hace su propia forma de amortiguación, y si usa la memoria virtual que en realidad está en el disco, va a tener un mal momento.

Es difícil proporcionar un "asesoramiento general" a prueba de retenciones sin una revisión completa de su servidor. Pero en mi experiencia, el 90% de los problemas son con las consultas y el diseño de la base de datos , no con la configuración del servidor.

Sin embargo, aquí tiene Una buena introducción a la optimización de configuración MySQL / INNODB por un buen humano (Peter Zaitsev). Espero que ayude.