Em 13/07/2012 12:37, Paulo Henrique BSD Brasil escreveu: > > 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 >> [email protected] >> 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. > hahahahahAh quando eu achava que já estava resolvido hahahahah
------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
