Possível fazer o MySQL usar mais de um núcleo?

Na verdade, discuti innodb_thread_concurrency com um MySQL Expert na conferência Percona Live NYC em maio de 2011 .

Aprendi algo surpreendente: Apesar da documentação, é melhor deixar innodb_thread_concurrencyem 0 (simultaneidade infinita). Dessa forma, o InnoDB decide o melhor número innodb_concurrency_ticketsa ser aberto para uma determinada configuração de instância do MySQL.

Depois de definir innodb_thread_concurrencycomo 0, você pode definir innodb_read_io_threadse innodb_write_io_threads(ambos desde o MySQL 5.1.38) para o valor máximo de 64. Isso deve envolver mais núcleos.

O MySQL usará automaticamente vários núcleos, portanto, sua carga de 25% é coincidência ¹ ou uma possível configuração incorreta no Solaris. Não vou fingir saber como ajustar o solaris, mas aqui está um artigo que aborda algumas informações de ajuste específicas do solaris .

As páginas de ajuste do InnoDB foram reformuladas no MySQL 5.5, então há algumas boas informações lá também. Das dicas de E/S do disco InnoDB :

Se a ferramenta superior do Unix ou o Gerenciador de Tarefas do Windows mostrar que a porcentagem de uso da CPU com sua carga de trabalho é inferior a 70%, sua carga de trabalho provavelmente está vinculada ao disco. Talvez você esteja fazendo muitos commits de transação ou o buffer pool é muito pequeno. Aumentar o buffer pool pode ajudar, mas não o defina como igual a mais de 80% da memória física.

Algumas outras coisas para verificar:

• Vale a pena testar a mudança do innodb_flush_method para O_DIRECT. Se isso ajudar, talvez seja necessário montar o sistema de arquivos com a forcedirectioopção

• Altere o innodb_flush_log_at_trx_commit de 1 para 0 (se você não se importa em perder o último segundo no travamento do mysql) ou 2 (se você não se importa em perder o último segundo no travamento do sistema operacional).

• Verifique o valor de innodb_use_sys_malloc . Este artigo tem mais informações sobre a variável.

  Naquela época, não havia bibliotecas de alocação de memória ajustadas para CPUs multi-core. Portanto, o InnoDB implementou seu próprio alocador de memória no subsistema mem. Esse alocador é guardado por um único mutex, que pode se tornar um gargalo.

  Mas há algumas advertências no final da seção sobre o que significa ativar a variável (ela está ativada por padrão na versão 5.5).

  Observe que quando o alocador de memória do InnoDB estiver desabilitado, o InnoDB ignorará o valor do parâmetro innodb_additional_mem_pool_size.

• É possível que a replicação esteja causando alguns dos problemas. Percebo que você não está interessado em paralelismo, mas pela descrição deste log de trabalho :

  Atualmente, a replicação não é bem dimensionada em máquinas com vários núcleos. O único encadeamento escravo executa eventos de replicação um por um e pode não lidar com uma carga produzida por várias conexões de cliente simultâneas atendidas pela CPU do servidor mestre separado.

Em última análise, o InnoDB pode não ser o melhor mecanismo para datawarehousing, devido às operações baseadas em disco que ocorrem. Você pode considerar alterar a(s) tabela(s) do datawarehouse para ser MyISAM compactado .

¹ _{Por coincidência, quero dizer que há um gargalo que impede que sua carga aumente acima de 25%, mas não é necessariamente um problema de núcleo único forçado.}

Nota: Esta resposta é sobre uma única conexão usando vários núcleos. A pergunta do OP era ambígua; ele assumiu incorretamente que o MySQL como um todo não poderia usar mais de um núcleo. As outras respostas apontam corretamente que o caso de teste 3-Alter é realmente limitado por E/S, portanto, falhando em provar a pergunta do título.

Uma única conexão usará apenas um único núcleo. (OK, o InnoDB usa outros threads, portanto, núcleos, para algum processamento de E/S, mas isso não é significativo.)

Você tinha 3 ALTERs, então você não estava usando muito mais do que 3 núcleos.

Infelizmente, nem mesmo PARTITION usa vários núcleos.

Até recentemente, várias conexões atingiriam o máximo após 4-8 núcleos. O Xtradb da Percona (incluído no MariaDB) faz melhor uso de vários núcleos, mas ainda assim apenas um por thread. Eles atingem o máximo em cerca de 32 núcleos.

(Atualização em 2015:) Várias conexões com 5,6 atingem o máximo de cerca de 48 núcleos. 5.7 promete ser ainda melhor. (É o que dizem os benchmarks da Oracle.) Mas ainda não há uso de vários núcleos para uma única conexão.

Atualização (depois de ir para o OpenWorld da Oracle): a nova versão 8.x não terá nenhum paralelismo.

Atualização adicional - 8.0.17 tem casos em que usará vários núcleos em poucas consultas selecionadas. (Isto é, não fique animado.)

IMHO e no caso de uso descrito, você nunca usará mais de um núcleo. O motivo é que sua carga de trabalho é vinculada a E/S, não vinculada à CPU. Como suas 3 conexões estão criando um novo Índice, cada uma delas precisa ler a tabela inteira do disco: isso é o que está demorando, não computando os Índices.

Considere que seu gargalo pode ser o desempenho de E/S do seu sistema de arquivos.

Além das configurações sugeridas por @RolandoMySQLDBA , também defino as noatimeconfigurações de montagem /etc/fstabpara a partição que contém meu diretório de dados mysql ( /data01/mysqlno meu caso, com /dev/sdb1montado para /data01).

Por padrão, o linux registra o tempo de acesso para TODA leitura ou gravação de disco que afeta negativamente o desempenho de E/S, especialmente para aplicativos de E/S altos, como bancos de dados. Isso significa que até mesmo a leitura de dados de um arquivo aciona uma gravação no disco... WAT!

Para desabilitar isso, adicione a noatimeopção de montagem /etc/fstabpara o ponto de montagem desejado da seguinte forma (exemplo no meu caso):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

Em seguida, remonte a partição:

mount -o,remount /data01

Isso deve aumentar o desempenho de leitura/gravação dos aplicativos que usam essa partição. MAS... nada supera manter todos os seus dados na memória.