Características do servidor

• RAM total do sistema: 8 GB (executando o MySQL + outras coisas que não o MySQL, ou seja, não dedicado ao MySQL)
• Número de núcleos da CPU: 6
• Eu tenho dados no db no valor de 2GB
• Eu tenho o tamanho do conjunto de buffers do InnoDB definido como 4 GB

Qual é melhor:

• Instâncias do conjunto de buffers Innodb definidas como 1?
• Instâncias do conjunto de buffers Innodb definidas para 2 (2 GB em cada)?
• Instâncias do conjunto de buffers Innodb definidas para 4 (1 GB em cada)?
• Instâncias do conjunto de buffers Innodb definidas como 8 (a configuração padrão)

Portanto, não tenho certeza de como raciocinar quando se trata de instâncias de buffer pool e também de todo "usar instâncias ou sofrer permuta do SO ao ter tamanho de buffer pool tão grande do InnoDB".

Quando volto ao MySQL 5.5, penso sobre a mesma coisa.

O que aprendi nesses anos foi o seguinte: Se o Buffer Pool era maior que a metade da RAM instalada e innodb_buffer_pool_instances era 1 (padrão para 5.5), a ameaça de troca era sempre iminente.

Eu discuti isso antes: Existe uma regra prática sobre o tamanho e o número de instâncias de um buffer pool? . Nesse post, mencionei um exemplo de cliente com 192 GB de RAM no servidor com buffer de 162 GB. Quando innodb_buffer_pool_instances tinha 1 anos, a troca aconteceu. Quando defino innodb_buffer_pool_instances como 2, as coisas ficaram muito melhores.

No seu caso, como o Buffer Pool é exatamente metade, um valor de 1 pode estar OK. Eu não teria chance. Eu configuraria para 2.

Como o MySQL 5.6 possui um padrão de 8, você não precisa mais pensar nisso.

Eu direi o seguinte: a resposta de akuzminsky tem o princípio mais alto . Minha resposta é apenas disparar do quadril com base em experiências passadas (boas e ruins).

O número de instâncias do buffer pool deve ser aumentado para evitar contenção de mutex no buffer pool.

Com o tamanho do buffer pool de 8 GB, duvido que você verá a contenção mutex do buffer pool.

ATUALIZAÇÃO 0 :

Mencionei o buffer pool de 8 GB na resposta, enquanto na pergunta original a memória total era de 8 GB. Claro, o buffer pool deve ter menos de 8 GB. 4 GB parece um bom começo, mas verifique se não há troca.

ATUALIZAÇÃO 1 :

// dos slides de Yasufumi (nas versões recentes do MySQL, a saída pode diferir ligeiramente)

Para determinar se há uma contenção no buffer pool, o mutex coleta uma dúzia de SHOW ENGINE INNODB STATUSamostras durante o horário de pico.

Agregue-o usando o snippet do 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 fornece uma saída 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

Se você vir uma contagem alta de esperas mutex do buffer pool, é hora de considerar várias instâncias do buffer pool. É improvável que a disputa aconteça em um buffer pool menor que ~ 48G.

Defina "swappiness" como 1 se o seu sistema operacional possuir. O problema pode ser um OOM excessivamente agressivo.

Eu sugeriria definir isso para corresponder ao número máximo de threads do MySQL que você deseja executar simultaneamente. Eu uso o número de núcleos.

Também defino innodb_read_io_threadse innodb_write_io_threadspara corresponder a esse número.

Se innodb_buffer_pool_instancesestiver muito baixo, é provável que seus threads fiquem presos nas esperas de semáforo. Isso faz com que a CPU e a E / S pareçam estar ociosas, mesmo que o sistema deva estar ocupado - e a latência do aplicativo atravessará o teto.