Em 13/7/2012 12:30, Patrick Tracanelli escreveu: > > Em 13/07/2012, às 12:00, Marcelo Gondim escreveu: > >> Evento: migração de um servidor de torrents de um Datacenter na Holanda >> para um Datacenter na Rússia. >> >> Holanda: >> Equipamento: 2x4 Core Xeon L5410 2.33GHz 16Gb de ram 2 discos SAS de 72Gb. >> SO: Debian 6.0 amd64 >> Programas: Apache 2.2.16 + PHP 5.3 + MySQL 5.1 - mais conhecido como >> LAMP rsrsrsr >> >> Rússia: >> Equipamento: 2x6 Core Xeon E5645 2.4Ghz 24Gb de ram 4 discos SAS de >> 147Gb 15k rpm em raid 0 >> >> 1ª tentativa: >> SO: FreeBSD 9.0-Stable amd64 >> Programas: Apache 2.2.22 + PHP 5.3 + MySQL 5.1 (BUILD_OPTIMIZED) - FAMP? :D >> >> Nessa tentativa eu reparei ao iniciar a aplicação loads muito altos na >> casa de 200 e cheguei à ver 1000. Também estava tendo problemas com o >> MySQL porque ao pegar o my-huge.cnf e alterar ele com os valores que eu >> já tinha no servidor antigo me deparei com o consumo de ram muito alto. >> Na aplicação web me gerava o seguinte erro quando chegava em umas 3000 >> conexões na base MySQL: >> >> DATABASE: mysql_connect: Can't create a new thread (errno 35); if you >> are not out of available memory, you can consult the manual for a >> possible OS-dependent bug >> >> Utilizei o tuning-primer pra ver os valores que estavam sendo usados e o >> que estava sendo consumido. >> >> 2ª tentativa: >> Em dado momento algumas pessoas me sugeriram usar o FreeBSD 8.3 por >> estar com uma performance melhor que o 9. Aí fiz todos os procedimentos >> abaixo passando o sistema de FreeBSD 9-stable para o 8.3-stable: >> >> - alterei o supfile de RELENG_9 para RELENG_8. >> - fiz o csup nele. >> - fiz o buildword e buildkernel >> - fiz installkernel e installworld >> - mergemaster, delete-old e delete-old-libs >> - reboot na criança >> - recompilei todos os pacotes instalados com o portmaster -a -f >> >> O load do sistema já melhorou absurdamente e passou à ficar na casa dos >> 1.x, 10.x mas nada com 3 casas rsrsrs Não sei se houve alguma mudança >> nisso entre o 8.3 e o 9. >> Mas o MySQL continuava estranho e como já estávamos alguns dias parados >> resolvemos voltar para o Linux. >> >> Resultado final: >> O problema do MySQL era a variável "read_rnd_buffer_size" que veio do >> my-huge.cnf e que o default dela é 8M. Tudo bem usar ela como default >> desde que você use o max_connections com valores baixos. O default do >> max_connections, se eu não me engano, é 150. Quando colocava o >> max_connections com 4000 o mysql avisava que ia precisar de uns 48G de >> ram pra trabalhar nessa quantidade e aí quando chegava em 2000 à 3000 >> conexões concorrentes já dava erro de falta de memória no MySQL. >> O que resolveu foi simplesmente comentar essa variável e tunnar as >> outras para as minhas necessidades e ficou 100% >> >> Pena que agora só poderemos tentar colocar o FreeBSD mais pra frente mas >> desta vez farei diferente algumas coisas: >> >> 1º Usarei RAID 10. >> 2º Sistema de arquivos UFS2+SUJ porque o ZFS consome muita memória, >> embora seja possível controlar isso, mas acredito que o UFS2+SUJ fique >> melhor. >> 3º Tunning melhor do sistema no sysctl, loader e kernel. >> >> Acho que é isso pessoal. >> >> Gondim > > Gondim, > > Só agora consegui ler essa thread que não peguei desde o início: que opera > hein? > > Bom de qualquer forma pra mim isso é um bug. Só não sei onde, mas isso é um > bug, ou do MySQL ou do MySQL no FreeBSD 9.0. > > Eu não pude ver direito ao certo se voce testou exatamente o mesmo my.cnf no > Linux, FreeBSD 8 e FreeBSD 9, aparentemente sim, e o bug só aconteceu no 9 > correto? Tem que comparar versão do MySQL q tinha no 9 e no 8 pra tirar a > limpo de quem é o bug mas o read_rnd_buffer_size nesse valor pra esse número > de sessões... estranho estourar, pior ainda gerar uma reserva de 32G de RAM > pra isso. O uso dessas 3 variaveis tem que ser combinadas, especialmente o > max_lenght: > > sort_buffer_size > max_length_for_sort_data > read_rnd_buffer_size > > Ou seja seu max_lenght_for_sort_data ou está alto demais ou seu banco tem > umas queries "order by/group by/sort" alienígenas ao ponto de rapidamnete > popularem todo o buffer. > > De qualquer forma, pelo jeito que o read_rnd_buffer_size funciona, fazendo > cache de ponteiro de memória crú na primeira vez que a pilha é ordenada, é > fácil ter algum bug em algum momento. Afinal ponteiro de memória só não é > mais delicado que ponteiro de ponteiro hehehe. > > Outra coisa é que a alocação desse buffer deve ser multiplicada pra cada > thread, e não pra cada conexão. Mas um indício que se temos > read_rnd_buffer_size * max_connections alocando memória temos um belo bug. > > Eu tenho aqui um com 12k max_conn e read_rnd_buffer_size em 4M que não é 8M > mas a mera multiplicação deveria aloprar a maquina que tem so 12G de RAM. No > entanto nesse momento por exemplo o show full processlist mostra 2.100 > conexões e o consumo de memoria é esse aqui: > > 43464 mysql 61 20 0 1631M 1395M uwait 6 39.9H 0.12% mysqld > > Ou seja 1.6G e apenas 61 threads então ou tem outro fator ferrando esse > tuning ou é um bug em algum lugar. > > Voce pode me responder quais eram as versões de MySQL em cada sistema? > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316...@sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >
Ja não bastava o Godim e até o Brandi, agora o Tracanelli na thread, a coisa ficou séria agora !!! Time de peso !!! Att. -- "Quando a Morte decide contar uma historia, A melhor ação que possa fazer é ouvi-la, e torcer por não ser a sua própria a tal história." Flames > /dev/null ( by Irado !! ). RIP Irado! Paulo Henrique. Analista de Sistemas / Programador BSDs Brasil. Genuine Unix/BSD User. Fone: (21) 9683-5433. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
