Alta CPU en el server MySQL Fusion-io

Acabo de terminar de leer este viejo Q & A que tenía información muy buena y detallada sobre una configuration similar a la nuestra, aunque por desgracia nuestro problema (ahora) no es con la replicación.

Rendimiento de replicación de MySQL

Tenemos un nuevo server de database maestro (versión de server: 5.5.27 -log MySQL Community Server) que se encuentra en un server de metal con las siguientes especificaciones:

  • 2 x Intel E5-2620-v2
  • Memoria de 64Gb
  • 2 x tarjeta Fusion-io 600Gb (Raid 1) para MySql
  • 1 x SSD para Centos 6.5
  • Red de 1 Gbps

HyperThreading no ha sido deshabilitado en el server, ya que hay opiniones contradictorias acerca de si esto ayuda en sistemas de memory grande, pero no estamos en contra de intentarlo.

Actualmente, nos duplicamos a 3 esclavos que se virtualizan en un clúster SSD. Estábamos replicando a 4, pero esto parecía demasiado para el cluster SSD y tuvimos períodos de lag.

Todas las tablas son InnoDB y DB maestro y las escrituras esclavas están entre 3.5K – 2.5K qps , mientras que las lecturas en el maestro son alnetworkingedor de 7.5k – 10k qps .

Los ajustes para el DB maestro son los siguientes:

long-query-time=10 slow-query-log max_connections=500 max_tmp_tables=1024 key_buffer = 1024M max_allowed_packet = 32M net_read_timeout=180 net_write_timeout=180 table_cache = 512 thread_cache = 32 thread_concurrency = 4 query_cache_type = 0 query_cache_size = 0M innodb_file_per_table innodb_file_format=barracuda innodb_buffer_pool_size=49152M innodb_buffer_pool_instances=2 innodb_read_io_threads=16 innodb_write_io_threads=16 innodb_io_capacity = 500 innodb_additional_mem_pool_size=20M innodb_log_file_size=1024M innodb_log_files_in_group = 2 innodb_doublewrite=0 innodb_flush_log_at_trx_commit=2 innodb_flush_method=O_DIRECT 

Nuestro problema es con la carga de la CPU, especialmente Sys Cpu. Como se puede ver en mpstat tenemos 0% iowait y muy alto% sys.

 Linux 2.6.32-431.29.2.el6.x86_64 13/11/14 _x86_64_ (24 CPU) 13:57:18 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 13:57:19 all 23.35 0.00 74.65 0.00 0.00 0.88 0.00 0.00 1.13 13:57:20 all 21.95 0.00 75.50 0.00 0.00 0.96 0.00 0.00 1.59 13:57:21 all 23.74 0.00 72.63 0.00 0.00 1.00 0.00 0.00 2.63 13:57:22 all 23.88 0.00 71.64 0.00 0.00 1.17 0.00 0.00 3.31 13:57:23 all 23.26 0.00 73.89 0.00 0.00 0.92 0.00 0.00 1.92 13:57:24 all 22.87 0.00 74.87 0.00 0.00 1.00 0.00 0.00 1.25 13:57:25 all 23.41 0.00 74.51 0.00 0.00 0.96 0.00 0.00 1.12 

Anteriormente, la database maestra se estaba ejecutando en un server virtual (el mismo clúster SSD que los esclavos). Tenía un anfitrión a sí mismo en el clúster vSphere que tenía:

  • 2 x Intel X5570
  • 32Gb de memory
  • SSD compartido desde el clúster

Nunca hubo ningún problema antes, el server funcionó sin falta durante muchos años, aunque con menor performance de SQL.

Las consultas son sencillas y los índices se han optimizado para las inserciones y actualizaciones, ya que las consultas complejas de los clientes se realizan en los esclavos. No hay borrados, sólo inserciones y actualizaciones. La mayoría de las tablas (todas grandes) tienen keys primarias.

El uso de la CPU parece crecer una vez que el búfer de memory está lleno, y MySql es la única aplicación que se ejecuta en el server.

El range de conexiones es de 200-400 con alnetworkingedor de 100-200 de los que se ejecutan. Innodb Buffer Pool Hit Ratio es 100%. No hay memory de intercambio alguna vez creada, así que no puedo ver que este sea el problema:

The MySQL “swap insanity” problem and the effects of the NUMA architecture

Tenemos un montón de historia con New Relic, pero por desgracia no puedo pegar en capturas de pantalla aquí.

He pasado por innumerables blogs y preguntas y respuestas como esto, pero no puedo encontrar ninguna causa ni solución, así que lo estoy poniendo por ahí .. ¿Alguna idea?

ACTUALIZAR

Parece que ahora puedo publicar capturas de pantalla. Estas dos capturas de Nueva reliquia muestran la carga del sistema y la carga de consulta en el server en una window de 6 horas con un reinicio de mysql en el medio.

Carga del sistema

Carga de la consulta

  • MySQL - El server se cerró sin actualizar el file PID
  • MySQL no libera descriptores de files temporales
  • ¿Cómo configuro rsyslog para hacer frente a los posts multilínea de MySQL Slow Query Log?
  • Actualización de MySQL 5.5 a 5.6
  • Configuración de replicación de MySQL 5.5 en ubuntu 12.04
  • Recuperar un server maestro MySQL arruinado del esclavo
  • La caching de consultas de MySQL está habilitada pero no se está utilizando
  • Error de longitud de key no válida al intentar conectar phpmyadmin a MySql remoto a través de SSL
  • One Solution collect form web for “Alta CPU en el server MySQL Fusion-io”

    InnoDB y FusionIO son muy CPU-agresivos individualmente, pero aún más juntos.

    Tengo posts antiguos sobre esto

    • Aug 25, 2013 : MySQL / Fusion IO Configuration Question
    • Jun 19, 2013 : MySQL utiliza demasiado CPU

    La key aquí es ser un poco más liberal en el ajuste InnoDB.

    SUGERENCIAS

    Debe elegir una o varias de las siguientes sugerencias:

    • Decida qué versión de MySQL desea tener
      • Actualizar a MySQL 5.6.21 ( mejor InnoDB Storage Engine + último parche de security )
      • Actualizar a MySQl 5.5.40 ( último parche de security )
    • Bump up innodb_buffer_pool_instances a 8 (Esto es MySQL 5.6 por defecto)
    • Máximo de los hilos de IO
      • innodb_read_io_threads = 64
      • innodb_write_io_threads = 64
    • Aumentar innodb_log_file_size = 128M para un mejor performance de escritura de logging
    • Doble innodb_io_capacity a 1000
    • Aumentar innodb_io_capacity_max a 2000 (sólo MySQL 5.6)
    • Aumentar innodb_purge_threads a 4 (sólo MySQL 5.6)
    • Comparar innodb_flush_log_at_trx_commit establecido en 0 en lugar de 2 para ver qué descarga más suave (tal vez ser seis de una docena y media de la otra)

    Darle una oportunidad !!!

    El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.