Introduziu métodos para otimizar o MYSQL em diversos aspectos para obter desempenho. A otimização é uma tarefa complexa, pois, em última análise, requer um entendimento de todo o sistema. Embora seja possível fazer alguma otimização local com pouco conhecimento do seu sistema/aplicação, quanto mais você quiser tornar seu sistema mais otimizado, você deve saber. também mais. Portanto, este capítulo tentará explicar e dar alguns exemplos de diferentes maneiras de otimizar o MySQL. Mas lembre-se de que sempre existem certas maneiras (cada vez mais difíceis) de fazer isso que são mais rápidas para o sistema. A parte mais importante para tornar seu sistema mais rápido é, obviamente, o design básico. Você também precisa saber que seu sistema fará coisas assim, e esse é o seu gargalo.
Busca de disco. O tempo que um disco leva para encontrar um dado. O tempo médio para um disco moderno usado em 1999 era geralmente inferior a 10 ms, portanto, em teoria, poderíamos buscar cerca de 1.000 vezes por segundo. discos e é difícil de medir. A maneira de otimizá-la é espalhar os dados por vários discos. Com o 1999 moderno, uma transferência de disco é de 10 a 20 Mb/s. Isso deve ser mais fácil de otimizar porque você pode ler de vários discos em ciclos de CPU paralelos. Quando lemos dados na memória (ou se já estiverem lá), precisamos processá-los para conseguir. nossos resultados. Quando Este é o fator limitante mais comum quando temos tabelas com memória relativamente pequena, mas com tabelas pequenas a velocidade geralmente não é um problema. A largura de banda da memória do cache se torna um gargalo na memória quando a CPU precisa de mais dados do que pode caber. no cache da CPU. Este é um gargalo incomum na maioria dos sistemas, mas você deve estar ciente disso. 10.2 Ajuste do sistema/tempo de compilação e dos parâmetros de inicialização Começamos com o nível do sistema, já que algumas dessas decisões são tomadas muito cedo. Outras vezes, uma rápida olhada nesta seção pode ser suficiente, pois não é crítica para o grande ganho, mas é sempre bom ter uma ideia de quão grande é o ganho neste nível. O sistema operacional padrão usado é importante. até certo ponto, você deve usar Solaris (porque os threads funcionam muito bem) ou Linux (porque o núcleo 2.2 tem um suporte SMP muito bom e em máquinas de 32 bits, o Linux tem um limite de tamanho de arquivo de 2G por padrão). Esperamos que isso seja corrigido em breve quando o novo sistema de arquivos for lançado (XFS). Como não executamos MySQL de produção em muitas plataformas, recomendamos que você teste a plataforma que pretende executar antes de escolhê-la.
Outras sugestões:
Se você tiver RAM suficiente, poderá remover todos os dispositivos de troca. Alguns sistemas operacionais usarão um dispositivo SWAP em alguns casos, mesmo se você tiver memória livre. Use a opção --skip -locking do MySQL para evitar bloqueio externo. Funcionalidade do MySQL, desde que esteja rodando apenas em um servidor. Apenas lembre-se de parar o servidor (ou bloquear as partes relevantes) antes de executar o myisamchk. Em alguns sistemas, esta opção é obrigatória porque o bloqueio externo não está disponível em nenhum dos casos. . Ao compilar com MIT-pthreads, a opção --skip-locking é padronizada como on (on) porque o rebanho() não é totalmente suportado pelo MIT-pthreads em todas as plataformas. o cliente) nos mesmos dados, você não pode usar --skip-locking, caso contrário, execute myisamchk na tabela sem primeiro liberar ou bloquear o servidor mysqld. Você ainda pode usar LOCK TABLES/UNLOCK TABLES, mesmo se estiver usando --skip. -bloqueio.
Como a compilação e a vinculação afetam a velocidade do MySQL
A maioria dos testes a seguir foram realizados no Linux e usando o benchmark MySQL, mas eles devem fornecer alguma indicação para outros sistemas operacionais e cargas de trabalho. Você obtém os executáveis mais rápidos ao vincular com -static Usando soquetes Unix Conectando-se a um banco de dados em vez de TCP. /IP também pode oferecer melhor desempenho. No Linux, você obterá o código mais rápido ao compilar com pgcc e -O6. Para compilar "sql_yacc.cc" com essas opções, você precisará de cerca de 200M de memória, porque gcc/pgcc requer muita memória. memória para tornar todas as funções inline. Ao configurar o MySQL, você também deve definir CXX=gcc para evitar a inclusão da biblioteca libstdc++ (apenas usando um compilador melhor ou opções de compilador melhores, você pode obter um 10). -30% de aceleração em seu aplicativo. Isso é especialmente importante se você mesmo compilar o servidor SQL. Na Intel, você deve, por exemplo, usar o pgcc ou o compilador Cygnus CodeFusion. Obtenha velocidade máxima. livre de erros o suficiente para otimizar a compilação do MySQL.
Aqui estão algumas folhas de medidas que fizemos:
Se você usar o pgcc com -O6 e compilar qualquer coisa, o servidor mysqld será 11% mais rápido que o gcc (com a string 99 version). Se você vincular dinamicamente (sem -static), o resultado será 13% mais lento. ainda é possível usar uma biblioteca MySQL vinculada dinamicamente. Somente o servidor é crítico para o desempenho. Se você usar TCP/IP em vez de soquetes Unix, o resultado será 7,5% mais lento. Em um Sun SPARCstation 10, o gcc2.7.3 é mais rápido que o Sun Pro C++. 4.2 é 13% mais rápido No Solaris 2.5.1, o MIT-pthreads é 8-12% mais lento que o Solaris com threads nativos em um único processador. Com mais carga/cpus, a diferença deve se tornar ainda maior. A distribuição Linux é compilada com pgcc e vinculada estaticamente.
Como mencionado anteriormente, a busca de disco é um grande gargalo de desempenho. Esse problema se torna cada vez mais óbvio quando os dados começam a crescer, de modo que o armazenamento em cache se torna impossível. Para bancos de dados grandes, onde é necessário ser mais ou menos aleatório para acessar os dados. confie no fato de que você precisará de pelo menos uma busca de disco para ler e várias buscas de disco para gravar. Para minimizar esse problema, use discos com tempos de busca baixos para aumentar o número de eixos de disco disponíveis (e assim reduzir a sobrecarga de busca). é possível vincular arquivos simbolicamente a discos diferentes ou dividir o disco. Usando links simbólicos, isso significa que você vincula simbolicamente os arquivos de índice/dados do diretório de dados normal ao outro disco (que também pode ser dividido). vezes melhor (se o disco não for usado para outras coisas). Consulte 10.2.2.1 Usando links simbólicos para bancos de dados e tabelas Split Split significa que você tem muitos discos e coloca o primeiro bloco em um disco, o segundo bloco está no segundo disco. , e o enésimo bloco está no (n mod number_of_disks)-ésimo disco, etc. Isso significa que se o tamanho normal dos dados for menor que o tamanho da divisão (ou perfeito (organizado de acordo), você obterá um desempenho um pouco melhor. Observe que a divisão é muito dependente do SO e do tamanho da divisão. Portanto, teste seu aplicativo com diferentes tamanhos de divisão. Consulte 10.8 Usando seu próprio benchmark. Observe que a divisão depende muito do SO e do tamanho da divisão. os parâmetros e o número de discos, você pode obter diferenças de ordens de magnitude. Observe que você deve optar por otimizar para acesso aleatório ou sequencial. Para confiabilidade, você pode querer usar RAID 0+ 1 (dividido + espelho), mas. neste caso, você precisará de unidades 2 * N para armazenar os dados das unidades N. Se você tiver dinheiro, esta é provavelmente a melhor opção. uma boa opção é ter os dados menos importantes (que podem ser reproduzidos) em um disco RAID 0 e os dados realmente importantes (como informações do host e arquivos de log) em discos RAID 0+ 1 ou RAID N, se você tiver muitos. de gravações devido à atualização de bits de paridade, o RAID N pode ser um problema. Você também pode definir parâmetros para o sistema de arquivos usado pelo banco de dados. o inode que pula a atualização, e isso evitará algumas buscas no disco.
Você pode mover tabelas e bancos de dados do diretório de banco de dados para outro local e substituí-los por símbolos vinculados ao novo local. Você pode fazer isso, por exemplo, movendo um banco de dados para um sistema de arquivos que tenha mais espaço livre. Avisos do MySQL Uma tabela é um link simbólico, que resolverá o link simbólico e usará a tabela para a qual realmente aponta. Ela funciona em todos os sistemas que suportam a chamada realpath() (pelo menos Linux e Solaris suportam realpath())! que não suportam realpath() Em seu sistema, você não deve acessar a tabela através de um caminho real e de um link simbólico ao mesmo tempo. Se você fizer isso, a tabela ficará inconsistente após qualquer atualização. O MySQL não suporta links de banco de dados! por padrão, desde que você não faça um link simbólico entre os bancos de dados, tudo funcionará bem. Suponha que você tenha um banco de dados db1 no diretório de dados MySQL e faça um link simbólico db2 apontando para db1:
shell&> cd /caminho/para/datadir
shell&> ln -s db1 db2
Agora, para qualquer tabela tbl_a em db1, também haverá uma tabela tbl_a em db2. Se um thread atualizar db1.tbl_a e outro thread atualizar db2.tbl_a, haverá problemas. "mysys/mf_format.c" deve ser alterado:
if (!lstat(to,&stat_buff)) /* Verifica se é um link simbólico */
if (S_ISLNK(stat_buff.st_mode) && realpath(to,buff))
Altere o código para este:
if (caminho real(para,buff))