Características del servidor

• RAM total del sistema: 8GB (ejecutando MySQL + otras cosas que no sean MySQL, es decir, no dedicado a MySQL)
• Número de núcleos de CPU: 6
• Tengo datos en la base de datos de aproximadamente 2 GB
• Tengo el tamaño de la agrupación de almacenamiento intermedio de InnoDB establecido en 4 GB

Cual es mejor:

• Innodb Buffer Pool Instances establecido en 1?
• Innodb Buffer Pool Instances establecido en 2 (2GB en cada uno)?
• Innodb Buffer Pool Instances establecido en 4 (1GB en cada uno)?
• Innodb Buffer Pool Instances establecido en 8 (la configuración predeterminada)

Por lo tanto, no estoy seguro de cómo razonar cuando se trata de instancias de agrupación de almacenamientos intermedios y tampoco de "usar instancias o sufrir un cambio de sistema operativo cuando se tiene un tamaño de agrupación de almacenamientos intermedios tan grande".

Cuando regrese a MySQL 5.5, pensaría en lo mismo.

Lo que aprendí durante esos años fue lo siguiente: si el grupo de búferes era más grande que la mitad de la RAM instalada e innodb_buffer_pool_instances era 1 (predeterminado para 5.5), la amenaza de intercambio siempre era inminente.

Discutí esto antes: ¿Existe una regla general con respecto al tamaño y el número de instancias de una agrupación de almacenamiento intermedio? . En esa publicación, mencioné un ejemplo de un cliente que tenía 192GB de RAM en el servidor con 162GB Buffer Pool. Cuando innodb_buffer_pool_instances fue 1, se produjo el intercambio. Cuando configuré innodb_buffer_pool_instances en 2, las cosas mejoraron mucho.

En su caso, dado que el Buffer Pool es exactamente la mitad, un valor de 1 puede estar bien. No lo arriesgaría. Lo pondría a 2.

Como MySQL 5.6 tiene un valor predeterminado de 8, no debería tener que pensarlo más.

Diré esto: la respuesta de akuzminsky tiene el principio más elevado . Mi respuesta es simplemente disparar desde la cadera en base a experiencias pasadas (buenas y malas).

Se debe aumentar el número de instancias de agrupación de almacenamiento intermedio para evitar la contención de mutex de la agrupación de almacenamiento intermedio.

Con el tamaño del grupo de búfer de 8 GB, dudo que alguna vez vea la contención de mutex del grupo de búfer.

ACTUALIZACIÓN 0 :

Menciono el grupo de búferes de 8 Gb en la respuesta, mientras que en la pregunta original la memoria total era de 8 GB. Claro, el grupo de búferes debe ser inferior a 8 GB. 4 GB suena como un buen comienzo, pero asegúrese de que no ocurra ningún intercambio.

ACTUALIZACIÓN 1 :

// de las diapositivas de Yasufumi (en versiones recientes de MySQL, la salida puede diferir ligeramente)

Para determinar si hay una contención en el grupo de búferes, mutex recolecta una docena de SHOW ENGINE INNODB STATUSmuestras durante el tiempo pico.

Luego agréguelo usando un fragmento de shell:

#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt 
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt

que da salida como esta:

.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139

Si ve un recuento alto de esperas de mutex de agrupación de almacenamientos intermedios, es hora de considerar varias instancias de agrupaciones de almacenamientos intermedios. Es improbable que la contención ocurra en una agrupación de almacenamiento intermedio más pequeña que ~ 48G.

Establezca "swappiness" en 1 si su sistema operativo tiene tal. El problema puede ser una OOM demasiado agresiva.

Sugeriría configurar esto para que coincida con el número máximo de subprocesos MySQL que desea ejecutar simultáneamente. Yo uso el número de núcleos.

También configuro innodb_read_io_threadsy innodb_write_io_threadspara que coincida con este número.

Si innodb_buffer_pool_instanceses demasiado bajo, es probable que sus hilos se atasquen en esperas de semáforos. Esto hace que tanto la CPU como la E / S parezcan inactivas, aunque el sistema debería estar ocupado, y la latencia de su aplicación irá por las nubes.