¿Cómo aprovechar al máximo MySQL en una máquina QuadCore con 16 GB de RAM?

Estoy ejecutando un servidor MySQL 5.5 en mi estación de trabajo para el análisis de datos científicos y me pregunto cómo configurar MySQL para aprovechar al máximo el rendimiento. Los tipos de consulta que normalmente ejecuto implican uniones de 10-20 tablas y pueden ejecutarse durante bastante tiempo, de uno a varios minutos, sin ninguna excepción. Solo muy pocos usuarios acceden a la base de datos al mismo tiempo (5 es el máximo). Moví el servidor de un Lenovo Thinkpad T61 con un núcleo dual de 2.2 GHz y 4 GB de RAM a la siguiente máquina nueva con componentes seleccionados a mano:

• Intel i7 3770, 4x 3.4 GHz (funcionando a 4x3.7 GHz)
• Chipset Z77
• 16 GB de RAM DDR3 1600
• Windows 7 Prof 64 bits
• El servidor Windows y MySQL se ejecuta en una unidad SSD Intel 520 series.

Las primeras pruebas (ejecutando la misma consulta en ambas máquinas) mostraron una mejora definitiva en la velocidad de la nueva, pero las consultas aún requieren mucho tiempo y esperaba un mayor impulso. Las consultas en cuestión están bastante bien optimizadas, es decir, todas las tablas tienen una clave adecuada que también se utiliza a partir de "explicar extendido".

Ahora a mi configuración actual de MySQL: Primero debo mencionar que me mudé de MyISAM a Innodb hace mucho tiempo.

Algunos de mis ajustes my.ini (es decir, desviaciones de la configuración predeterminada):

# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
#tmp_table_size=35M
tmp_table_size=4000M
max_heap_table_size=4000M

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system.  Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
#innodb_buffer_pool_size=96M
innodb_buffer_pool_size=800M

general-log
expire_logs_days = 60
general_log_file = "F:/my_query_mysql.log"
log-output = TABLE
optimizer_search_depth = 0 #meant to cure the "statistics state" bug in some queries

Me gustaría saber si alguien sugeriría cambios en los números anteriores o incluso configuraciones adicionales que no conozco.

Agradecería cualquier comentario útil.

Steve

EDITAR: Tengo dos consultas que involucran combinaciones en 10-20 tablas y las ejecuté en mi computadora portátil Lenovo y la nueva PC. La consulta # 1 tomó 3m36s en la nueva máquina frente a 9m11s en la computadora portátil; La consulta # 2 tomó 22.5s en la estación de trabajo frente a 48.5s en la computadora portátil. Por lo tanto, la velocidad de ejecución mejoró aproximadamente por el factor 2-2.5. En la estación de trabajo, ni siquiera se utilizó el 50% de la RAM. La carga promedio de la CPU en los cuatro núcleos (según lo informado por el Administrador de tareas de Windows) fue solo del 13%. La carga por núcleo (según lo informado por Core Temp) fue de aproximadamente 25-40% para UN núcleo, mientras que fue <= 10% para los demás, lo que indica que MySQL no utiliza múltiples núcleos para una sola consulta .

Como está ejecutando MySQL 5.5, es posible que desee considerar configurar InnoDB para acceder a múltiples núcleos

Estas son las configuraciones que debe usar

innodb_thread_concurrency establece el límite superior en el número de subprocesos concurrentes que InnoDB puede mantener abiertos. El mejor número de ronda para establecer es (2 X Número de CPU) + Número de discos. ACTUALIZACIÓN : Como aprendí de primera mano de la Conferencia de Percona NYC, debe establecer esto en 0 para alertar a InnoDB Storage Engine para que encuentre la mejor cantidad de subprocesos para el entorno en el que se está ejecutando.

innodb_concurrency_tickets establece el número de subprocesos que pueden omitir la comprobación de concurrencia con impunidad. Una vez alcanzado ese límite, la comprobación de concurrencia de subprocesos vuelve a ser la norma.

innodb_commit_concurrency establece el número de transacciones concurrentes que pueden confirmarse. Dado que el valor predeterminado es 0, no establecer esto permite que cualquier número de transacciones se confirme simultáneamente.

innodb_thread_sleep_delay establece el número de milisegundos que un subproceso InnoDB puede estar inactivo antes de volver a entrar en la cola InnoDB. El valor predeterminado es 10000 (10 segundos).

innodb_read_io_threads e innodb_write_io_threads (ambos desde MySQL 5.1.38) asignan el número especificado de hilos para lecturas y escrituras. El valor predeterminado es 4 y el máximo es 64.

innodb_replication_delay impone un retraso de subproceso en un esclavo si se alcanza innodb_thread_concurrency.

Aquí están mis publicaciones anteriores en MySQL 5.5 y la activación de múltiples núcleos para InnoDB

• Jun 01, 2012: Tengo 16 GB de RAM, ¿cómo debo configurar el servidor MySQL?
• May 07, 2012: Rendimiento del servidor MySQL
• Apr 26, 2012: ¿El rendimiento de la CPU es relevante para un servidor de base de datos?
• Mar 16, 2012: Uso de múltiples núcleos para consultas MySQL individuales en Debian
• Oct 07, 2011: ¿Debería usar un motor de almacenamiento que no sea MyISAM para optimizar estas tablas o debería obtener mejores discos?
• Sep 20, 2011: Multi núcleos y rendimiento MySQL
• Sep 12, 2011: ¿Es posible hacer que MySQL use más de un núcleo?

Percona: el consultor líder de MySQL ofrece un asistente de configuración de MySQL . Le permite configurar my.cnf/my.inisegún la configuración de su sistema.

También la gente de Percona ha lanzado un libro llamado " High Performance MySQL ". La tercera edición fue lanzada recientemente y cubre el ajuste con gran detalle.

Uso de memoria: consulte http://mysql.rjweb.org/doc.php/memory (la mayoría de los sintonizables no harán la diferencia suficiente).

max_heap_table_size = 4000M es peligrosamente alto. Si 4 usuarios lo necesitan, está sin RAM e intercambiando. El intercambio perjudica el rendimiento mucho más que prácticamente cualquier cosa.

Consultas que demoran más de unos segundos: deben estudiarse para mejorar; proporcione SHOW CREATE TABLE; MOSTRAR ESTADO DE LA MESA; EXPLICAR SELECCIONAR

También puede considerar otras opciones. Como PostgreSQL en FreeBSD. Pero cambiar de Windows a Linux aumentará su rendimiento.