Manual de Referência do MySQL :: 2.6.2 Notas Linux (Todas as versões)

As notas abaixo a respeito da glibc aplicam-se somente na situação quando o MySQL é construido por você mesmo. Se você está executando Linux em uma máquina x86, na maioria dos casos é muito melhor para você usar nosso binário. Nós ligamos nossos binários com a melhor versão alterada da glibc, podemos escolher as melhores opções do compilador, em uma tentativa de torná-la funcional para um servidor muito exigido. Para um usuário comum, mesmo para configurações com várias conexões concorrentes e/ou tabelas excedendo o limite de 2 GB, nosso binário é, na maioria das vezes, a melhor escolha. Portanto se você ler o texto abaixo, e está em dúvida sobre o que deve fazer, tente usar o nosso binário primeiro para ver se ele preenche suas necessidades, e preocupe-se com uma construção própria apenas se você descobrir que nosso binário não é bom o suficiente para você. Neste caso, iríamos apreciar se fosse feito uma observação sobre isto, para que possamos fazer uma melhor versão bináris da próxima vez.

O MySQL usa LinuxThreads no Linux. Se você usa uma versão do Linux que não tenha a glibc2, você deve instalar LinuxThreads antes de tentar compilar o MySQL. Você pode obter o LinuxThreads em http://www.mysql.com/downloads/os-linux.html.

NOTA: Temos visto alguns problemas estranhos com o Linux 2.2.14 e MySQL em sistemas SMP; Se você tem um sistema SMP, recomendamos a atualização para o Linux 2.4! Seu sistema ficará mais rápido e mais estável.

Perceba que as versões da glibc iguais ou anteriores à Versão 2.1.1 tem um bug fatal no tratamento do pthread_mutex_timedwait, que é usado quando você executar instruções INSERT DELAYED. Recomendamos não usar INSERT DELAYED antes de atualizar a glibc.

Se você planeja ter mais de 1000 conexões simultâneas, será necessário fazer algumas alterações na LinuxThreads, recompile-a e religue o MySQL ao novo libpthread.a. Aumente PTHREAD_THREADS_MAX em sysdeps/unix/sysv/linux/bits/local_lim.h para 4096 e abaixe o STACK_SIZE no linuxthreads/internals.h para 256KB. Os caminhos são relativos à raiz da glibc. Note que o MySQL não será estável com cerca de 600-1000 conexões se o valor de STACK_SIZE for o padrão de 2MB.

Se você tiver um problema com o MySQL, no qual ele não consiga abrir vários arquivos ou conexões, pode ser que você não tenha configurado o Linux para lidar com o número de arquivos suficiente.

No Linux 2.2 e posteriores, você pode conferir o valor para a alocação dos arquivos fazendo:

cat /proc/sys/fs/file-max
cat /proc/sys/fs/dquot-max
cat /proc/sys/fs/super-max

Se você possui mais de 16M de memória, deve ser adicionado o seguinte no seu script de boot (ex. /etc/rc/boot.local no SuSE Linux):

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

Você também pode executar os comandos acima da linha de comando como root, mas neste caso, os antigos limites voltarão a ser usados na próxima vez que o computador for reiniciado.

De forma alternativa, você pode configurar estes parâmteros durante a inicialização usando a ferramenta sysctl, que é usada por muitas distribuições Linux (No SuSE a partir da versão 8.0). Apenas grave os seguintes valores em um arquivo chamado /etc/sysctl.conf:

# Aumente alguns valores para o MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

You should also add the following to /etc/my.cnf:

[mysqld_safe]
open-files-limit=8192

Os parâmetros acima permitem o MySQL criar até 8192 conexões + arquivos.

A constante STACK_SIZE na LinuxThreads controla o espaçamento das pilhas threads no espaço de endereçamento. Ela necessita ser grande o bastante para que tenha espaço o suficiente para a pilha de cada thread, mas pequena o bastante para manter a pilha de alguma thread executando dos dados globais mysqld. Infelizmente, a implementação Linux de mmap(), como descobrimos em experiências, irá desmapear uma região já mapeada se você solicitar o mapeamento de um endereço já em uso, zerando os dados de toda a página ao invés de retoernar. um erro. Portanto a segurança do mysqld ou qualquer outra aplicação baseada em threads depende do comportamento gentil do código que cria as threads. O usuário deve tomar medidas para certirficar-se que o número de threads em funcionamento em qualquer hora seja suficientemente baixo para que as pilhas das threads permaneçam longe do monte global. Com mysqld você deve reforçar este comportamento "gentil" configurando um valor razoável para a variável max_connections.

Se você mesmo construiu o MySQL e não deseja confusões corrigindo LinuxThreads, você deve configurar max_connections para um valor máximo de 500. Ele ainda deve ser menor se você tiver uma chave grande para o buffer, grandes tabelas heap, ou outras coisas que fazem o mysqld alocar muita memória ou se você estiver executando um kernel 2.2 com o patch de 2GB. Se você estiver usando nosso binário ou RPM versão 3.23.25 ou posterior, você pode seguramente configurar max_connections para 1500, assumindo que não há uma grande chave de buffer ou tabelas heap com grande quantidade de dados. Quanto mais você reduz STACK_SIZE em LinuxThreads mais threads você pode criar seguramente. Recomendamos os valores entre 128K e 256K.

Se você usa várias conexões simultâneas, você pode sofrer com um "recurso" do kernel 2.2 que penaliza um processo por bifurcar-se ou clonar um filho na tentativa de prevenir um ataque de separação. Isto faz com que o MySQL não consiga fazer uma bom escalonamento, quando o número de clientes simultâneos cresce. Em sistemas com CPU única, temos visto isto se manifestar em uma criação muito lenta das threads, tornando a conexão ao MySQL muito lenta. Em sistemas de múltiplas CPUs, temos observado uma queda gradual na velocidade das consultas quando o número de clientes aumenta. No processo de tentar encontrar uma solução, recebemos um patch do kernel de um de nossos usuários, que alega fazer muita diferença para seu site. O patch está disponível aqui (http://www.mysql.com/Downloads/Patches/linux-fork.patch). Atualmente temos feito testes extensivos deste patch nos sistemas de desenvolvimento e produção. A performance do MySQL obtem uma melhora significativa, sem causar problemas e atualmente o recomendamos para nossos usuários que continuando trabalhando com servidores muito carregados em kernels 2.2. Este detalhe foi corrigido no kernel 2.4, portanto, se você não está satisfeito com a performance atual do seu sistema, melhor do que aplicar um patch ao seu kernel 2.2, pode ser mais fácil simplesmente atualizar para o 2.4, que lhe dará também uma melhora em seu sistemas SMP em adição à correção do bug discutido aqui.

Estamos testando o MySQL no kernel 2.4 em uma máquina com 2 processadores e descobrimos que o MySQL escalona muito melhor - virtualmente, não há nenhuma perda de desempenho no throughput das consultas até cerca de 1000 clientes, e o fator da escala do MySQL (computado com a razão do throughput máximo para o thoughput de cada cliente.) foi de 180%. Temos observado resultados similares em sistemas com 4 processadores - virtualmente não há perda de desempenho quando o número de clientes é incrementado até 1000 e o fator da escala foi de 300%. Portanto para um servidor SMP muito carregado nós definitivamente recomendamos o kernel 2.4. Nós descobrimos que é essencial executar o processo mysqld com a mais alta prioridade possível no kernel 2.4 para obter performance máxima. Isto pode ser feito adicionando o comando renice -20 $$ ao mysqld_safe. Nos nossos testes em uma máquina com 4 processadores, o aumento da prioridade nos deu 60% de aumento no throughput com 400 clientes.

Atualmente estamos tentando coletar mais informações sobre como o MySQL atua no kernel 2.4 em sistemas com 4 e 8 processadores. Se você tem acesso a um sistema deste porte e tem feito alguns benchmarks, por favor envie um email para <docs@mysql.com> com os resultados - iremos incluí-los neste manual.

Existe outro detalhe que afeta muito a performance do MySQL, especialmente em sistemas multi processados. A implementação de mutex em LinuxThreads na glibc-2.1 é muito ruim para programas com várias threads que travam o mutex por um tempo curto. Em um sistema SMP, ironicamente, se você liga o MySQL com LinuxThreads sem modificações, removendo processadores da máquina, a performance do MySQL é melhorada em alguns casos. Para corrigir este comportamento, disponibilizamos um patch para glibc 2.1.3, em linuxthreads-2.1-patch

Com a glibc-2.2.2, o MySQL versão 3.23.36 irá usar o mutex adaptativo, que é muito melhor,mesmo que o patch na glibc-2.1.3. Avisamos, entretando, que sobre algumas condições, o código mutex no glibc-2.2.2 overspins, que prejudica a performance do MySQL. A chance desta condição pode ser reduzida mudando a prioridade do processo mysqld para a prioridade mais alta. Nós também corrigimos o comportamento overspin com um patch, disponível em http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. Ele combina a correção do overspin, número máximo de threads e espaçamento das pilhas em um único patch. Você precisará aplicá-lo no diretório linuxthreads com patch -p0 </tmp/linuxthreads-2.2.2.patch. Esperamos que seja incluído de alguma forma nos futuros lançamentos da glibc-2.2. De qualquer forma, se você ligar com glibc-2.2.2, ainda será necessário corrigir STACK_SIZE e PTHREAD_THREADS_MAX. Temos esperanças que os padrões serão corrigidos para valores mais aceitáveis para configurações pesadasa do MySQL no futuro, então sua construção poderá ser reduzida a ./configure; make; make install.

Recomendamos que você use os patches acima para construir uma versão estática especial de libpthread.a e use-a somente para ligações estáticas com o MySQL. Sabemos que os patches são seguros para o MySQL e pode melhorar significamente sua performance, mas não podemos dizer nada sobre outras aplicações. Se você ligar outras aplicações coma a versão modificada da biblioteca ou construir uma versão alterada compartilhada e instalá-la no seu sistema, você estará fazendo por sua conta e risco e tenha atenção com outras aplicações que dependem de LinuxThreads.

Se você passar por problemas estranhos durante a instalação do MySQL ou com travamentos de alguns utilitários comuns, é muito provável que eles são relacionados a problemas de bibliotecas ou compilador. Se for este o caso, o uso de nosso binário será a solução.

Um problema conhecido com a distribuição binária é que com antigos sistemas Linux que usam libc (como o RedHat 4.x ou Slackware), você obterá alguns problemas não fatais com resolução de nomes. See Secção 2.6.2.1, “Notas Linux para distribuições binárias”.

Quando estiver usando LinuxThreads você verá um mínimo de três processos em execução. Estes são de fato, threads. Existirá uma thread para o gerenciador LinuxThreads, uma thread para lidar com conexões e uma thread para tartar de alarmes e sinais.

Perceba que o kernel Linux e a biblioteca LinuxThread pode por padrão ter apenas 1024 threads. Isto significa que você pode ter até 1021 conexões ao MySQL em um sistema sem correção. A página http://www.volano.com/linuxnotes.html contém informações sobre como contornar este limite.

Se você ver um processo mysqld daemon finalizado com ps, isto normalmente significa que você encontrou um bug no MySQL ou que tenha uma tabela corrompida. See Secção A.4.1, “O Que Fazer Se o MySQL Continua Falhando”.

Para obter um descarga do core no Linux se o mysqld finalizar com um sinal SIGSEGV, você pode iniciar o mysqld com a opção --core-file. Perceba que provavelmente você também precisará aumentar o core file size adicionando ulimit -c 1000000 para mysqld_safe ou iniciar mysqld_safe com --core-file-sizes=1000000, See Secção 4.8.2, “mysqld-safe, o wrapper do mysqld”.

Se você estiver ligando seu próprio cliente MySQL e obter o erro:

ld.so.1: ./my: fatal: libmysqlclient.so.4:
open failed: No such file or directory

Quando executá-los, o problema pode ser evitado com um dos seguintes métodos:

Se você estiver usando o compilador Fujitsu (fcc / FCC) você terá alguns problemas compilando o MySQL porque os arquivos de cabeçalho Linux são muito orientados ao gcc.

A seguinte linha configure deve funcionar com fcc/FCC:

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
-DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib \
-K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const \
-Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
'-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql \
--enable-assembler --with-mysqld-ldflags=-all-static --disable-shared \
--with-low-memory