Uau, você tem algum hardware extremamente robusto para esse problema. Não há muito mais que você possa usar em termos de hardware, com exceção da atualização para as CPUs Sandy / Ivy Bridge para obter um desempenho 20-50% melhor nas pesquisas da Btree, etc.
Por favor, note que meu forte é Innodb, então eu vou
- Ignore que você é myisam e aja como se não fizesse diferença.
- Suponha que esse problema seja suficiente para fazer a atualização. Sim, é uma atualização.
O Innodb pode ajudar a tirar grande proveito de toda essa memória armazenando essas linhas acessadas com frequência em seu buffer pool. Você pode ajustá-lo para o tamanho que desejar (digamos 80% da memória) e novas leituras / gravações permanecem na memória até que seja necessário enviá-las para o disco para liberar mais espaço para os dados mais recentes acessados. A memória é uma ordem de magnitude mais rápida que seus FusionIOs.
Existem muitos outros recursos do Innodb, como hashes adaptáveis, mecanismos de travamento automático, etc. que podem ser um benefício para o seu ambiente. Você, no entanto, conhece seus dados melhor do que eu.
No mundo innodb, uma boa solução a curto prazo é otimizar seu escravo - você realmente precisa de todos os índices do seu escravo que possui no seu mestre? Os índices são uma bola e uma corrente nas inserções / atualizações / exclusões, MESMO com os cartões Fusion IO. IOPS não são tudo aqui. Os processos de ponte Sandy / Ivy têm uma taxa de transferência de memória e desempenho de computação muito melhores - eles podem fazer uma enorme diferença no Westmeres que você tem agora. (Figura 20-50% do total). Remova todos os índices que você não precisa no escravo!
Segundo, e quase certamente se aplica apenas ao innodb, é que o mk-prefetch pode saber quais atualizações e antes que o escravo as grave. Isso permite que o mk-prefetch execute uma consulta de leitura primeiro, forçando os dados a ficarem na memória no momento em que a única substituição executa a consulta de gravação. Isso significa que os dados estão na memória e não no fusionIO, um rápido ganho de desempenho em ordem de magnitude. Isso faz uma enorme diferença, mais do que se poderia esperar. Muitas empresas usam isso como uma solução permanente. Saiba mais consultando o Percona Toolkit .
Terceiro, e mais importante, depois de atualizar para o Innodb, faça o check-out definitivo do Tokutek. Esses caras têm algumas coisas incrivelmente impressionantes que excedem em muito o desempenho de gravação / atualização / exclusão do Innodb. Eles consideram a velocidade de replicação aprimorada como um dos principais benefícios, e você pode ver nos seus benchmarks por que o IOPS maluco do Fusions ainda não o ajudará no caso de Btrees . (Nota: não foram verificados por mim de forma independente.) Eles usam um substituto substituto de um índice btree que, apesar de terrivelmente mais complexo, melhora muitas das limitações de velocidade algorítmica dos índices btree.
Estou pensando em adotar o Tokutek. Se eles liberam tanta velocidade de gravação, isso permite que eu adicione mais índices. Como eles compactam os dados e os índices em proporções maravilhosas (25x, eles citam), você nem paga um preço (desempenho, manutenção) por um aumento de dados. Você paga ($) pelo mecanismo, no entanto, US $ 2500 / ano por GB pré-compactado, IIRC. Eles têm descontos se você replicar os dados, mas você pode até instalar o Tokutek no seu escravo e manter o seu mestre como está. Confira os detalhes técnicos na palestra MIT Algoritms Open Courseware . Como alternativa, eles têm toneladas de material técnico em seu blog e whitepapers regulares para quem não tem 1:20 para assistir ao vídeo. Acredito que este vídeo também fornece a fórmula Big-O para a rapidez com que as leituras são. Eu tenhosupor que as leituras são mais lentas (sempre há uma troca!), mas a fórmula é muito complexa para eu avaliar quanto. Eles alegam que é aproximadamente o mesmo, mas eu prefiro entender a matemática (provavelmente não!). Você pode estar em uma situação melhor para descobrir isso do que eu.
Ps: Eu não sou afiliado à Tokutek, nunca usei o produto deles e eles nem sabem que eu estou olhando para eles.
Atualização :
Vejo que você tem outras perguntas nesta página e pensei em inserir:
Primeiro, a pré-busca de escravos quase certamente não funcionará para o myisam, a menos que você tenha um ambiente excepcional. Isso ocorre principalmente porque a pré-busca bloqueará as próprias tabelas nas quais você pretende gravar ou o encadeamento escravo tem a tabela bloqueada que o daemon de pré-busca precisa. Se suas tabelas são extremamente bem equilibradas para replicação e tabelas diferentes estão sendo gravadas de maneira round-robin, isso pode funcionar - mas lembre-se de que isso é muito teórico. O livro "Mysql de alto desempenho" possui mais informações na seção "Problemas de replicação".
Segundo, presumivelmente o seu escravo mantém uma carga de 1,0 a 1,5, pode ser maior se você tiver outros procs ou consultas em execução, mas uma linha de base de 1,0. Isso significa que você provavelmente está vinculado à CPU, o que provavelmente ocorre com o seu FusionIO a bordo. Como mencionei anteriormente, Sandy / Ivy Bridge vai dar um pouco mais de força, mas provavelmente não o suficiente para passar pelos tempos mais difíceis com um atraso mínimo. Se a carga neste escravo é principalmente somente de gravação (ou seja, não há muitas leituras), sua CPU está quase certamente gastando seu tempo calculando posições para inserções / exclusões de btree. Isso deve reforçar meu argumento acima sobre a remoção de índices não críticos - você sempre pode adicioná-los novamente mais tarde. Desabilitar o hyperthreading não funcionará, mais CPU não é seu inimigo. Depois de obter mais de 32 GB de RAM, digamos 64 GB, você precisa se preocupar com a distribuição de RAM, mas mesmo assim os sintomas são diferentes.
Finalmente, e o mais importante (não pule esta parte;)), suponho que agora você esteja executando o RBR (replicação baseada em linha) porque mencionou um aumento de desempenho não trivial ao alterná-lo também. No entanto - pode haver uma maneira de obter ainda mais desempenho aqui. O bug 53375 do Mysql pode se manifestar se você tiver tabelas sendo replicadas sem chave primária. O escravo basicamente não é inteligente o suficiente para usar qualquer coisa, exceto uma chave primária; portanto, a ausência de uma força o thread de replicação a fazer uma varredura completa da tabela para cada atualização. Uma correção é simplesmente adicionar uma chave primária de aumento automático benigno e substituto. Eu faria isso apenas se a tabela fosse grande (digamos, várias dezenas de milhares de linhas ou mais). Obviamente, isso tem o custo de ter outro índice na tabela, que aumenta o preço que você paga na CPU. Observe que existem muito poucos argumentos teóricos contra isso, pois o InnoDB adiciona um nos bastidores, se não o fizer. O fantasma, no entanto, não é uma defesa útil contra o 53375. O tungstênio também pode superar esse problema, mas você precisa ter certeza de que, ao usar o tungstênio, sua codificação está correta. A última vez que joguei com ele, morreria horrivelmente quando qualquer sequência não UTF8 precisava ser replicada. Foi nessa época que desisti.
