Configuración MySQL 5.1 InnoDB / 24GB RAM - carga alta bi-xeon

10

Estoy ejecutando una aplicación de Facebook que actualmente tiene entre 300 y 600 usuarios concurrentes (y en crecimiento). Para preparar el hardware para el crecimiento, cambié mi i7 / 12gb ram / 2x 80gb intel x25 ssd (debian 5.0 / mysql 5.0 / 64bit) en un bi-xeon / 24gb ram / 2x 120gb intel 320 ssd (ubuntu 10.10 / mysql 5.1 / 64 bits).

ahora me enfrento al problema de que el rendimiento es peor que en el "cuadro más pequeño". En ambos servidores he estado usando nginx / php fcgi para servir el contenido.

Estoy usando innodb solamente, con lecturas / escrituras de aproximadamente 65% / 35%. Alrededor de 800 - 1000 qps, pero todas las consultas son simples y nunca se unen a más de 1 tabla adicional. Todos los índices están configurados y no se registra ninguna consulta individual en el registro lento (> 2s). En este momento tengo alrededor de 400 mb de datos (alrededor de 1 gb con índices) esperando que se duplique cada mes.

Adoro a todos los que podrían darme una pista de qué cambiar para que funcione mejor.

La configuración anterior en el i7 box era así (myisam / innodb mixto), con un rendimiento bastante bueno hasta 800+ usuarios.

viejo my.cnf

   key_buffer              = 3000M
   max_allowed_packet      = 128M
   thread_stack            = 192K
   thread_cache_size       = 8
   max_connections        = 400
   table_cache            = 8000
   thread_concurrency     = 16
   query_cache_limit       = 8M
   query_cache_size        = 128M
   wait_timeout            = 10
   interactive_timeout     = 10
   connect_timeout         = 600
   low_priority_updates    = 1
   join_buffer_size        = 8M
   read_buffer_size        = 2M
   sort_buffer_size        = 3M
   myisam_sort_buffer_size = 32M
   read_rnd_buffer_size    = 4M
   innodb_buffer_pool_size = 3G
   innodb_log_buffer_size  = 8M

La nueva configuración en la caja bi-xeon es así (innodb puro), causando una gran carga con más de 300 usuarios. Alrededor de 30 procesos mysql se encuentran en la parte superior de la lista de procesos.

E / S de disco:

    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              36.28    0.00    1.60    0.17    0.00   61.95

my.cnf

    key_buffer              = 64M
    max_allowed_packet      = 1M
    thread_stack            = 192K
    thread_cache_size       = 128
    max_connections        = 500
    table_cache            = 512
    #thread_concurrency     = 10
    sort_buffer_size        = 256K
    read_buffer_size        = 256K
    read_rnd_buffer_size    = 256K
    tmp_table_size          = 32M
    max_heap_table_size     = 32M
    query_cache_limit       = 1M
    query_cache_size        = 128M
    query_cache_type        = 1

    innodb_file_per_table = 1
    innodb_data_file_path = ibdata1:1000M:autoextend
    innodb_buffer_pool_size = 16384M
    innodb_additional_mem_pool_size = 8M
    innodb_flush_log_at_trx_commit = 1
    innodb_support_xa = 0
    innodb_lock_wait_timeout = 50
    innodb_flush_method=O_DIRECT
    innodb_log_files_in_group = 2
    innodb_log_file_size = 128M
    innodb_log_buffer_size = 8M
    innodb_thread_concurrency = 12
mysql performance innodb my.cnf Kilian
fuente
Hmmm, ¿está skip-name-resolvedeshabilitado y se puede habilitar?
Escrito el

Respuestas:

7

He escrito algunas publicaciones en el StackExchnage

  1. Ajuste de MySQL para InnoDB y MyISAM
  2. Cómo mantener InnoDB Diskspace bajo control
  3. Otro punto de vista sobre la administración de MySQL Diskspace
  4. Punto de vista sobre la optimización de InnoDB
  5. Ajuste fino de InnoDB

Lea estos para obtener la orientación que necesita.

Ahora, para problemas más urgentes: mencionaste que tienes 400 MB de datos, 1 GB con índices. Eso me da miedo de que sus índices sean un 50% más grandes que los datos. Sin embargo, dado que todos sus datos son InnoDB y está satisfecho con el rendimiento de la consulta actual, su configuración es más que adecuada, especialmente los 16384 MB de innodb_buffer_pool_size. Eso es 16 GB. Estás todo listo allí. Pero espera !!! ¿Su innodb_log_file_size es 128M? Demasiado pequeño dado el grupo de búfer de 16 GB. Debe cambiar el tamaño de los archivos ib_logfile (establezca innodb_log_file_size en 2047M).

Puede estar experimentando carga por subproceso. Intente configurar sus búferes de conexión (join_buffer_size, sort_buffer_size, read_buffer_size, read_rnd_buffer_size)

De mi parte: ¿Por qué MySQL dice que no tengo memoria?

De @DTest: ¿Cómo se calcula la variable mysql max_ connections ?

Darle una oportunidad !!!

RolandoMySQLDBA
fuente
se trataba de establecer algunos índices ... ahora tengo algunas columnas que se indexan dos veces en otras combinaciones ... y tengo 35 GB de datos ahora y 10'000qps ... y funciona sin problemas como la seda.
Kilian
0
  • ¿Convertiste algunas tablas de MyISAM a InnoDB?
    Si es así, verifique si hay mejoras / degradaciones sutiles en el rendimiento en http://mysql.rjweb.org/doc.php/myisam2innodb
  • innodb_flush_log_at_trx_commit = 1
    - provoca una escritura en el registro después de cada transacción. Considera usar = 2.
  • max_connections- SHOW GLOBAL STATUS LIKE 'max_used_connections'
    - eso te dirá cuántos necesitabas desde el inicio.

  • consulta caché:

    query_cache_size        = 128M
query_cache_type        = 1

    Estos pueden ser dolorosos. Arriba, digamos, 50Mel control de calidad dedica demasiado tiempo al mantenimiento. Tenerlo también ONpuede ser un desperdicio. Hacer SHOW GLOBAL STATUS LIKE 'Qc%'para verificar la efectividad.

Rick James
fuente