Curiosamente, no MySQL 5.5, agora você pode ter vários pools de buffers innodb.
Os parâmetros com os quais você se importa são
Em cerca de um mês, estou programado para implementar 112 buffer pools de innodb para um cliente. Eu vou deixar você saber como foi.
UPDATE 2011-02-27 21:57 EDT
Descobri que o valor máximo para innodb_buffer_pool_instances é 64. Decidi configurar 144 GB, então configurei innodb_buffer_pool_instances como 18 e innodb_buffer_pool_size como 8. Atualmente, estou carregando o servidor com 450 GB
ATUALIZAÇÃO 28-04-2011 13:44 EDT
Experimentei vários pools de buffers do InnoDB. Havia muita trava de rosca e contenção. Mudei para um único buffer pool de 162 GB + definindo read_io_threads e write_io_threads para 64 (valor máximo). Isso funcionou muito melhor.
ATUALIZAÇÃO 2012-07-03 17:27 EDT
Eu aprendi algo incrível sobre o MySQL. Se você alocar um único conjunto de buffers monolíticos do InnoDB maior que o total de unidades instaladas dividido pelo número de CPUs físicas , o sistema operacional será instado para a troca de memória a intervalos regulares devido a um conjunto de buffers completo do InnoDB. A opção do MySQL 5.5 conhecida como innodb_buffer_pool_instances pode ser usada para dividir o buffer pool. Ontem, implementei isso corretamente para o cliente que mencionei na minha resposta no ano passado. Ainda tenho 162 GB para o buffer pool do cliente. Eu configurei a opção innodb_buffer_pool_instances do servidor como 2 porque cada servidor de banco de dados é duplo hexacore. Eu estava pensando em defini-lo para 12, mas então um colega me mostrou um blog de Jeremy Cole no MySQL e Swappiness. Depois de ler, coloquei-o em prática imediatamente para o meu cliente. Eu executei este comando
numactl --hardware
Vi um mapeamento de 192 GB de RAM do servidor como 96 GB para cada núcleo físico. Portanto, defino o innodb_buffer_pool_instances como 2. As coisas estão boas agora. Vou atualizar minha resposta para ver como isso afeta a troca de memória pelos próximos 2 meses.