Em um dos meus ambientes de produção, temos duas instâncias em execução em um cluster RedHat, com uma instância de produção associada ao cluster.
Temos memória principal de 125G com buffer pool 24G InnoDB ocupado pela instância1 e 12G ocupados pela instância2, que não está associado ao cluster RedHat. Os logs de dados e de transação estão localizados na partição do disco LVM com um sistema de arquivos ext3.
Para melhorar o desempenho e melhorar a taxa de transferência de E / S, decidi mudar innodb_flush_methodpara O_DIRECT.
Com referência à documentação do MySQL:
Onde os dados e arquivos de log do InnoDB estão localizados em uma SAN, foi constatado que a configuração
innodb_flush_methodparaO_DIRECTpode degradar o desempenho deSELECTinstruções simples por um fator de três.
Referindo-se ao MySQL Ver 2 e 3 de alto desempenho, ele afirmou que os desenvolvedores do InnoDB encontraram erros no uso innodb_flush_method=O_DSYNC. O_SYNCe O_DSYNCsão semelhantes a fsync()e fdatasync(): O_SYNCsincroniza dados e metadados, enquanto O_DSYNCsincroniza apenas dados.
Se tudo isso parecia muita explicação sem conselhos, aqui está o conselho:
se você usa um sistema operacional semelhante ao Unix e seu controlador RAID possui um cache de gravação suportado por bateria, recomendamos o uso
O_DIRECT. Caso contrário, o padrão ouO_DIRECTprovavelmente será a melhor opção, dependendo do seu aplicativo.
Ao pesquisar no Google, recebi este relatório de benchmark: on O_DSYNCvsO_DIRECT
Relatório de Benchmark: =================== Teste Transacional Complexo de 1B Linhas, 64 threads * SAN O_DIRECT: solicitações de leitura / gravação: 31560140 (8766,61 por segundo) * SAN O_DSYNC: solicitações de leitura / gravação: 5179457 (1438,52 por segundo) * SAN fdatasync: solicitações de leitura / gravação: 9445774 (2623,66 por segundo) * O_DIRECT do disco local: solicitações de leitura / gravação: 3258595 (905,06 por segundo) * O_DSYNC do disco local: solicitações de leitura / gravação: 3494632 (970,65 por segundo) * Fdatasync do disco local: solicitações de leitura / gravação: 4223757 (1173.04 por segundo.
No entanto, O_DIRECTdesativa o cache no nível do SO, onde o cache duplo pode ser desativado, o que mostra uma taxa de transferência de E / S melhor.
É bom ir com O_DIRECTe não O_DSYNC? Essas duas opções são um pouco confusas. Qual opção pode mostrar melhor rendimento de E / S e aprimoramento no desempenho sem nenhum impacto nos dados, leituras / gravações especialmente na produção? Alguma sugestão melhor com base na sua experiência pessoal?
Eu pude ver o Rolando Update no post :
Ainda há uma leve confusão em ambos os parâmetros. Onde eu pude ver a maioria dos modelos de configuração de produção usando
O_DIRECT, eu não vi nenhum onde recomendarO_DSYNC.
Sistema
- MySQL 5.1.51-enterprise-gpl-pro-log
- Servidor Red Hat Enterprise Linux versão 5.5
- DELL DRAC com o Raid Controller com um cache de gravação de bateria de 512 MB
- Controladores Dell PERC H700 com uma unidade de backup de bateria (BBU).
Informação adicional
mysql> mostra variáveis como 'innodb_thread_concurrency'; + --------------------------- + ------- + | Nome da variável | Valor + --------------------------- + ------- + | innodb_thread_concurrency | 96 + --------------------------- + ------- + 1 linha no conjunto (0,00 s) mysql> mostra variáveis como 'innodb_read_io_threads'; Conjunto vazio (0,00 seg) mysql> mostra variáveis como 'innodb_write_io_threads'; Conjunto vazio (0,00 seg)
Estamos usando o plug-in padrão, então eu publiquei as informações do status do InnoDB:
mysql> SELECT * FROM Plug-ins ONDE PLUGIN_NAME GOSTA DE '% innodb%' E PLUGIN_TYPE COMO 'STORAGE ENGINE' \ G
*************************** 1. linha ******************** *******
PLUGIN_NAME: InnoDB
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ATIVO
PLUGIN_TYPE: MOTOR DE ARMAZENAMENTO
PLUGIN_TYPE_VERSION: 50151.0
PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
PLUGIN_AUTHOR: Innobase OY
PLUGIN_DESCRIPTION: suporta transações, bloqueio no nível de linha e chaves estrangeiras
PLUGIN_LICENSE: GPL
1 linha no conjunto (0,00 s)