Notas Linux (Todas as vers˜ oes)

As notas abaixo a respeito da glibc aplicam-se somente na situa¸c˜ao quando o MySQL ´e construido por vocˆe mesmo. Se vocˆe est´a executando Linux em uma m´aquina x86, na maioria dos casos ´e muito melhor para vocˆe usar nosso bin´ario. N´os ligamos nossos bin´arios com a melhor vers˜ao alterada daglibc, podemos escolher as melhores op¸c˜oes do compilador, em uma tentativa de torn´a-la funcional para um servidor muito exigido. Para um usu´ario comum, mesmo para configura¸c˜oes com v´arias conex˜oes concorrentes e/ou tabelas excedendo o limite de 2 GB, nosso bin´ario ´e, na maioria das vezes, a melhor escolha. Portanto se vocˆe ler o texto abaixo, e est´a em d´uvida sobre o que deve fazer, tente usar o nosso bin´ario primeiro para ver se ele preenche suas necessidades, e preocupe-se com uma constru¸c˜ao pr´opria apenas se vocˆe descobrir que nosso bin´ario n˜ao ´e bom o suficiente para vocˆe. Neste caso, ir´iamos apreciar se fosse feito uma observa¸c˜ao sobre isto, para que possamos fazer uma melhor vers˜ao bin´aris da pr´oxima vez.

O MySQL usa LinuxThreads no Linux. Se vocˆe usa uma vers˜ao do Linux que n˜ao tenha a glibc2, vocˆe deve instalar LinuxThreads antes de tentar compilar o MySQL. Vocˆe 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ˆe tem um sistema SMP, recomendamos a atualiza¸c˜ao para o Linux 2.4! Seu sistema ficar´a mais r´apido e mais est´avel.

Perceba que as vers˜oes da glibc iguais ou anteriores `a Vers˜ao 2.1.1 tem um bug fatal no tratamento do pthread_mutex_timedwait, que ´e usado quando vocˆe executar instru¸c˜oes INSERT DELAYED. Recomendamos n˜ao usarINSERT DELAYED antes de atualizar aglibc.

Se vocˆe planeja ter mais de 1000 conex˜oes simultˆaneas, ser´a necess´ario fazer algumas altera¸c˜oes 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˜ao relativos `a raiz daglibc. Note que o MySQL n˜ao ser´a est´avel com cerca de 600-1000 conex˜oes se o valor deSTACK_SIZE for o padr˜ao de 2MB.

Se vocˆe tiver um problema com o MySQL, no qual ele n˜ao consiga abrir v´arios arquivos ou conex˜oes, pode ser que vocˆe n˜ao tenha configurado o Linux para lidar com o n´umero de arquivos suficiente.

No Linux 2.2 e posteriores, vocˆe pode conferir o valor para a aloca¸c˜ao dos arquivos fazendo:

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

Se vocˆe possui mais de 16M de mem´oria, 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ˆe tamb´em pode executar os comandos acima da linha de comando como root, mas neste caso, os antigos limites voltar˜ao a ser usados na pr´oxima vez que o computador for reiniciado.

De forma alternativa, vocˆe pode configurar estes parˆamteros durante a inicializa¸c˜ao usando a ferramentasysctl, que ´e usada por muitas distribui¸c˜oes Linux (No SuSE a partir da vers˜ao 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ˆametros acima permitem o MySQL criar at´e 8192 conex˜oes+arquivos.

A constante STACK_SIZE na LinuxThreads controla o espa¸camento das pilhas threads no espa¸co de endere¸camento. Ela necessita ser grande o bastante para que tenha espa¸co o suficiente para a pilha de cada thread, mas pequena o bastante para manter a pilha de al-guma thread executando dos dados globaismysqld. Infelizmente, a implementa¸c˜ao Linux de mmap(), como descobrimos em experiˆencias, ir´a desmapear uma regi˜ao j´a mapeada se vocˆe solicitar o mapeamento de um endere¸co j´a em uso, zerando os dados de toda a p´agina ao inv´es de retoernar. um erro. Portanto a seguran¸ca domysqldou qualquer outra aplica¸c˜ao baseada em threads depende do comportamento gentil do c´odigo que cria as threads. O usu´ario deve tomar medidas para certirficar-se que o n´umero de threads em funcionamento em qualquer hora seja suficientemente baixo para que as pilhas das threads permane¸cam longe do monte global. Commysqld vocˆe deve refor¸car este comportamento"gentil" con-figurando um valor razo´avel para a vari´avel max_connections.

Se vocˆe mesmo construiu o MySQL e n˜ao deseja confus˜oes corrigindo LinuxThreads, vocˆe deve configurarmax_connectionspara um valor m´aximo de 500. Ele ainda deve ser menor se vocˆe tiver uma chave grande para o buffer, grandes tabelas heap, ou outras coisas que fazem o mysqld alocar muita mem´oria ou se vocˆe estiver executando um kernel 2.2 com o patch de 2GB. Se vocˆe estiver usando nosso bin´ario ou RPM vers˜ao 3.23.25 ou posterior, vocˆe pode seguramente configurar max_connections para 1500, assumindo que n˜ao h´a uma grande chave de buffer ou tabelas heap com grande quantidade de dados. Quanto mais vocˆe reduz STACK_SIZEem LinuxThreads mais threads vocˆe pode criar seguramente.

Recomendamos os valores entre 128K e 256K.

Se vocˆe usa v´arias conex˜oes simultˆaneas, vocˆe 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¸c˜ao. Isto faz com que o MySQL n˜ao consiga fazer uma bom escalonamento, quando o n´umero de clientes simultˆaneos cresce. Em sistemas com CPU

´

unica, temos visto isto se manifestar em uma cria¸c˜ao muito lenta das threads, tornando a conex˜ao ao MySQL muito lenta. Em sistemas de m´ultiplas CPUs, temos observado uma queda gradual na velocidade das consultas quando o n´umero de clientes aumenta.

No processo de tentar encontrar uma solu¸c˜ao, recebemos um patch do kernel de um de nossos usu´arios, que alega fazer muita diferen¸ca para seu site. O patch est´a dispon´ivel aqui (http://www.mysql.com/Downloads/Patches/linux-fork.patch). Atualmente temos feito testes extensivos deste patch nos sistemas de desenvolvimento e produ¸c˜ao.

A performance do MySQL obtem uma melhora significativa, sem causar problemas e atualmente o recomendamos para nossos usu´arios que continuando trabalhando com servidores muito carregados em kernels 2.2. Este detalhe foi corrigido no kernel 2.4, portanto, se vocˆe n˜ao est´a satisfeito com a performance atual do seu sistema, melhor do que aplicar um patch ao seu kernel 2.2, pode ser mais f´acil simplesmente atualizar para o 2.4, que lhe dar´a tamb´em uma melhora em seu sistemas SMP em adi¸c˜ao `a corre¸c˜ao do bug discutido aqui.

Estamos testando o MySQL no kernel 2.4 em uma m´aquina com 2 processadores e desco-brimos que o MySQL escalona muito melhor - virtualmente, n˜ao h´a nenhuma perda de desempenho no throughput das consultas at´e cerca de 1000 clientes, e o fator da escala do MySQL (computado com a raz˜ao do throughput m´aximo para o thoughput de cada cliente.) foi de 180%. Temos observado resultados similares em sistemas com 4 processadores - vir-tualmente n˜ao h´a perda de desempenho quando o n´umero de clientes ´e incrementado at´e 1000 e o fator da escala foi de 300%. Portanto para um servidor SMP muito carregado n´os definitivamente recomendamos o kernel 2.4. N´os descobrimos que ´e essencial executar o processomysqld com a mais alta prioridade poss´ivel no kernel 2.4 para obter performance m´axima. Isto pode ser feito adicionando o comandorenice -20 $$ ao mysqld_safe. Nos nossos testes em uma m´aquina com 4 processadores, o aumento da prioridade nos deu 60%

de aumento no throughput com 400 clientes.

Atualmente estamos tentando coletar mais informa¸c˜oes sobre como oMySQLatua no kernel 2.4 em sistemas com 4 e 8 processadores. Se vocˆe tem acesso a um sistema deste porte e tem feito alguns benchmarks, por favor envie um email paradocs@mysql.comcom os resultados - iremos inclu´i-los neste manual.

Existe outro detalhe que afeta muito a performance do MySQL, especialmente em sistemas multi processados. A implementa¸c˜ao de mutex em LinuxThreads na glibc-2.1 ´e muito ruim para programas com v´arias threads que travam o mutex por um tempo curto. Em um sistema SMP, ironicamente, se vocˆe liga o MySQL com LinuxThreads sem modifica¸c˜oes, removendo processadores da m´aquina, a performance do MySQL ´e melhorada em alguns casos. Para corrigir este compor-tamento, disponibilizamos um patch para glibc 2.1.3, em linuxthreads-2.1-patch ( http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch)

Com a glibc-2.2.2, o MySQL vers˜ao 3.23.36 ir´a usar o mutex adaptativo, que ´e muito melhor,mesmo que o patch na glibc-2.1.3. Avisamos, entretando, que sobre algumas condi¸c˜oes, o c´odigo mutex noglibc-2.2.2overspins, que prejudica a performance do MySQL.

A chance desta condi¸c˜ao pode ser reduzida mudando a prioridade do processomysqldpara a prioridade mais alta. N´os tamb´em corrigimos o comportamento overspin com um patch, dispon´ivel em http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch.

Ele combina a corre¸c˜ao do overspin, n´umero m´aximo de threads e espa¸camento das pilhas em um ´unico patch. Vocˆe precisar´a aplic´a-lo no diret´orio linuxthreads com patch -p0

</tmp/linuxthreads-2.2.2.patch. Esperamos que seja inclu´ido de alguma forma nos futuros lan¸camentos da glibc-2.2. De qualquer forma, se vocˆe ligar com glibc-2.2.2, ainda ser´a necess´ario corrigir STACK_SIZEePTHREAD_THREADS_MAX. Temos esperan¸cas que os padr˜oes ser˜ao corrigidos para valores mais aceit´aveis para configura¸c˜oes pesadasa do MySQL no futuro, ent˜ao sua constru¸c˜ao poder´a ser reduzida a ./configure; make; make install.

Recomendamos que vocˆe use os patches acima para construir uma vers˜ao est´atica especial de libpthread.a e use-a somente para liga¸c˜oes est´aticas com o MySQL. Sabemos que os patches s˜ao seguros para oMySQLe pode melhorar significamente sua performance, mas n˜ao podemos dizer nada sobre outras aplica¸c˜oes. Se vocˆe ligar outras aplica¸c˜oes coma a vers˜ao modificada da biblioteca ou construir uma vers˜ao alterada compartilhada e instal´a-la no seu sistema, vocˆe estar´a fazendo por sua conta e risco e tenha aten¸c˜ao com outras aplica¸c˜oes que dependem deLinuxThreads.

Se vocˆe passar por problemas estranhos durante a instala¸c˜ao do MySQL ou com travamentos de alguns utilit´arios comuns, ´e muito prov´avel que eles s˜ao relacionados a problemas de bibliotecas ou compilador. Se for este o caso, o uso de nosso bin´ario ser´a a solu¸c˜ao.

Um problema conhecido com a distribui¸c˜ao bin´aria ´e que com antigos sistemas Linux que usam libc (como o RedHat 4.x ou Slackware), vocˆe obter´a alguns problemas n˜ao fatais com resolu¸c˜ao de nomes. Veja Se¸c˜ao 2.6.2.1 [Binary notes-Linux], P´agina 141.

Quando estiver usando LinuxThreads vocˆe ver´a um m´inimo de trˆes processos em execu¸c˜ao.

Estes s˜ao de fato, threads. Existir´a uma thread para o gerenciador LinuxThreads, uma thread para lidar com conex˜oes e uma thread para tartar de alarmes e sinais.

Perceba que o kernel Linux e a biblioteca LinuxThread pode por padr˜ao ter apenas 1024 threads. Isto significa que vocˆe pode ter at´e 1021 conex˜oes ao MySQL em um sistema sem corre¸c˜ao. A p´aginahttp://www.volano.com/linuxnotes.htmlcont´em informa¸c˜oes sobre como contornar este limite.

Se vocˆe ver um processo mysqlddaemon finalizado com ps, isto normalmente significa que vocˆe encontrou um bug no MySQL ou que tenha uma tabela corrompida. Veja Se¸c˜ao A.4.1 [Crashing], P´agina 921.

Para obter um descarga do core no Linux se omysqldfinalizar com um sinal SIGSEGV, vocˆe pode iniciar omysqldcom a op¸c˜ao--core-file. Perceba que provavelmente vocˆe tamb´em precisar´a aumentar o core file size adicionando ulimit -c 1000000 paramysqld_safe ou iniciarmysqld_safecom--core-file-sizes=1000000, Veja Se¸c˜ao 4.8.2 [safe_mysqld], P´agina 332.

Se vocˆe estiver ligando seu pr´oprio cliente MySQL e obter o erro:

ld.so.1: ./my: fatal: libmysqlclient.so.4:

open failed: No such file or directory

Quando execut´a-los, o problema pode ser evitado com um dos seguintes m´etodos:

• Ligue o cliente com a seguinte op¸c˜ao (no lugar de -Lpath): -Wl,r/path-libmysqlclient.so.

• Copie libmysqclient.sopara ‘/usr/lib’.

• Adicione o caminho do diret´orio onde libmysqlclient.so est´a localizado para a vari´avel de ambiente LD_RUN_PATHantes de executar seu cliente.

Se vocˆe estiver usando o compilador Fujitsu (fcc / FCC) vocˆe ter´a alguns problemas com-pilando o MySQL porque os arquivos de cabe¸calho Linux s˜ao muito orientados aogcc.

A seguinte linhaconfigure deve funcionar comfcc/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

2.6.2.1 Notas Linux para distribui¸c˜ oes bin´ arias

O MySQL necessita pelo menos do Linux vers˜ao 2.0

Aviso: Percebemos que alguns usu´arios do MySQL tiveram serios problemas de estabilidade com o MySQL e o kernel 2.2.14 do Linux. Se vocˆe estiver usando este kernel vocˆe deve atualiz´a-lo para o 2.2.19 (ou posterior) ou para o kernel 2.4. Se vocˆe tiver um gabinete multi-cpu, ent˜ao vocˆe deve considerar seriamente o uso do kernel 2.4 uma vez que ele lhe trar´a uma melhora significante na velocidade.

A vers˜ao bin´aria ´e ligada com-static, que significa que vocˆe normalmente n˜ao precisa se preocupar com qual vers˜ao das bibliotecas do sistema vocˆe tem. Vocˆe n˜ao precisa insta-lar LinuxThreads. Um programa ligado com a op¸c˜ao -static ´e um pouco maior que um programa ligado dinamicamente e tamb´em um pouco mais r´apido (3-5%). Um problema, entretanto, ´e que vocˆe n˜ao pode usar fun¸c˜oes definidas pelo usu´ario (UDF) com um pro-grama ligado estaticamente. Se vocˆe for escrever ou usar fun¸c˜oes UDF (isto ´e algo para programadores C ou C++), vocˆe deve compilar o MySQL, usando liga¸c˜oes dinamicas.

Se vocˆe estiver usando um sistema baseado emlibc(em vez de um sistemaglibc2), vocˆe, provavelmente, ter´a alguns problemas com resolu¸c˜ao de nomes de m´aquinas egetpwnam() com a vers˜ao bin´aria. (Isto ´e porque oglibc infelizmente depende de algumas bibliotecas externas para resolver nomes de m´aquinas e getpwent(), mesmo quando compilado com -static). Neste caso, vocˆe provavelmente obter´a a seguinte mensagem de erro quando executarmysql_install_db:

Sorry, the host ’xxxx’ could not be looked up

ou o seguinte erro quando vocˆe tentar executar mysqldcom a op¸c˜ao--user:

getpwnam: No such file or directory

Vocˆe pode resolver este problema usando de um dos modos seguintes:

• Obtenha uma distribui¸c˜ao fonte do MySQL (uma distribui¸c˜ao RPM ou tar.gz) e a instale.

• Executemysql_install_db --force; Isto n˜ao executar´a o testeresolveipnomysql_

install_db. O lado ruim ´e que vocˆe n˜ao poder´a usar nomes de m´aquinas nas tabelas de permiss˜oes; vocˆe deve usar n´umeros IP no lugar (exceto para localhost). Se vocˆe

estiver usando uma release antiga do MySQL que n˜ao suporte --force, vocˆe deve remover o teste resolveipno mysql_installcom um editor.

• Iniciemysqldcom su no lugar de usar--user.

As distribui¸c˜oes bin´arias Linux-Intel e RPM do MySQL s˜ao configuradas para o m´aximo de desempenho poss´ivel. N´os sempre tentamos usar o compilador mais r´apido e est´avel dispon´ivel.

Suporte MySQL ao Perl exige Perl Vers˜ao 5.004 03 ou mais novo.

Em algumas vers˜oes 2.2 do kernel Linux,vocˆe pode obter o erro Resource temporarily unavailable quando vocˆe faz v´arias novas conex˜oes para um servidor mysqld sobre TCP/IP.

O problema ´e que o Linux tem um atraso entre o momento em que vocˆe fecha um socket TCP/IP at´e que ele seja realmente liberado pelo sistema. Como s´o existe espa¸co para um n´umero finito de slots TCP/IP, vocˆe ir´a obter o erro acima se vocˆe tentar fazer muitas novas conex˜oes TCP/IP durante um pequeno tempo, como quando vocˆe executa o benchmark do MySQL ‘test-connect’ sobre TCP/IP.

N´os enviamos emails sobre este problema v´arias vezes para diferentes listas de discuss˜ao Linux mas nunca conseguimos resolver este problema apropriadamente.

A ´unica ’corre¸c˜ao’ conhecida , para este problema ´e usar conex˜oes persistentes nos seus clientes ou usar sockets, se vocˆe estiver executando o servidor de banco de dados e clientes na mesma m´aquina. N´os experamos que o kernelLinux 2.4corrija este problema no futuro.

2.6.2.2 Notas Linux x86

O MySQL exige a vers˜ao 5.4.12 ou mais nova dalibc. Sabe-se que funciona com a libc 5.4.46. A vers˜ao 2.0.6 e posterior daglibc tamb´em deve funcionar. Existem alguns prob-lemas com os RPMsglibc da RedHat, portanto se vocˆe tiver problemas, confira se existe alguma atualiza¸c˜ao! Sabemos que os RPMs glibc2.0.7-19 e 2.0.7-29 funcionam.

Se vocˆe estiver usando o Red Hat 8.0 ou uma nova bibliotecaglibc2.2.x, vocˆe deve iniciar o mysqldcom a op¸c˜ao --thread-stack=192K (Use -O thread_stack=192K antes do MySQL 4). Se vocˆe n˜ao fizer isto omysqldfinlizar´a em gethostbyaddr()porque a nova biblioteca glibc exige mais de 128K de mem´oria na pilha para esta chamada. Este tamanho de pilha

´e o padr˜ao agora no MySQL 4.0.10 e acima.

Se vocˆe est´a usando o gcc 3.0 e acima para compilar o MySQL, vocˆe deve instalar a bibliotecalibstdc++v3antes de compilar o MySQL; se vocˆe n˜ao fizer isto, vocˆe obter´a um erro sobre um s´imbolo __cxa_pure_virtualperdido durante a liga¸c˜ao.

Em algumas distribui¸c˜oes Linux mais antigas,configurepode produzir um erro como este:

Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file.

See the Installation chapter in the Reference Manual.

Fa¸ca apenas o que a mensagem de erro diz e adicione um caractere sublinhado para a macro _P que tem somente um caractere sublinhado e ent˜ao tente novamente.

Vocˆe pode obter alguns aviso quando estiver compilando; os mostrados abaixo podem ser ignorados:

mysqld.cc -o objs-thread/mysqld.o

mysqld.cc: In function ‘void init_signals()’:

mysqld.cc:315: warning: assignment of negative value ‘-1’ to

‘long unsigned int’

mysqld.cc: In function ‘void * signal_hand(void *)’:

mysqld.cc:346: warning: assignment of negative value ‘-1’ to

‘long unsigned int’

O mysql.server pode ser encontrado no diret´orio ‘share/mysql’ sob o diret´orio de in-stala¸c˜ao MySQL ou no diret´orio ‘support-files’ da ´arvore fonte MySQL.

Se o mysqld sempre descarregar um core na inicializa¸c˜ao, o problema pode ser que vocˆe tenha um antigo ‘/lib/libc.a’. Tente renome´a-lo depois remova ‘sql/mysqld’ e fa¸ca um novo make installe tente novamente. Este problema foi relatado em algumas instala¸c˜oes Slackware.

Se vocˆe obter o seguinte erro quando ligar o mysqld, significa que seu ‘libg++.a’ n˜ao est´a instalado corretamente:

/usr/lib/libc.a(putc.o): In function ‘_IO_putc’:

putc.o(.text+0x0): multiple definition of ‘_IO_putc’

Vocˆe pode evitar o uso de ‘libg++.a’ executando configure desta forma:

shell> CXX=gcc ./configure

2.6.2.3 Notas Linux SPARC

Em algumas implementa¸c˜oes, readdir_r() est´a quebrada. O sintoma ´e que SHOW DATABASES sempre retorna um conjunto vazio. Isto pode ser corrigido removendo HAVE_READDIR_R do ‘config.h’ depois de configurar e antes de compilar.

2.6.2.4 Notas Linux Alpha

O MySQL Vers˜ao 3.23.12 ´e a primeira vers˜ao do MySQL que ´e testada no Linux-Alpha. Se vocˆe planeja usar o MySQL no Linux-Alpha, vocˆe deve ter certeza que possui esta vers˜ao ou mais nova.

Temos testado o MySQL no Alpha com nossos pacotes de benchmarks e testes, e ele parece funcinar muito bem.

Quando n´os compilamos o bin´arios MySQL padr˜oes, n´os est´avamos usando SuSE 6.4, kernel

Quando n´os compilamos o bin´arios MySQL padr˜oes, n´os est´avamos usando SuSE 6.4, kernel

No documento 1 Informa¸c˜ oes Gerais . . . . 1 (páginas 171-179)