Em 12/07/2012 16:18, Otavio Augusto escreveu: > Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com > Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem > nehum tunning e rodando perfeito
Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. > > Em 12 de julho de 2012 16:10, Nilton Jose Rizzo <ri...@i805.com.br> escreveu: >> Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu >>> Em 11/07/2012 14:52, Edson Brandi escreveu: >>>> Em 11 de julho de 2012 14:33, Marcelo Gondim <gon...@bsdinfo.com.br> >>>> escreveu: >>>>> Será que sem querer descobri algo interessante? rsrsrsrsrs >>>> Marcelo, >>>> >>>> Estava dando uma olhada em como o mysql tuning primer >>>> (https://launchpad.net/mysql-tuning-primer/), chega nos números. >>>> >>>> Pelo que vi ele não está usando nenhuma variavel do sistema >>>> operacional, e esta fazendo praticamente todas as contas tendo como >>>> input variaveis do mysql. >>>> >>>> Com base nesta lógica de calculo a unica explicação que vejo pros >>>> numeros estarem diferentes é se estas variaveis forem diferentes entre >>>> o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me >>>> parece ser algo relacionado ao sistema operacional. >>> Pois é mas se pegar as confs copiar de um pra outro usando as mesmas >>> variáveis e só mudando o max_connection já dá uma grande diferença. >>> Também quero encontrar uma solução para isso. Também pensei no >>> seguinte: e se o tuning-primer não tivesse funcionando corretamente >>> no FreeBSD, os valores estivesses errados e fossem proximos dos do >>> Linux. Então tudo deveria funcionar normalmente mas não funciona. >>> Quando estouro com o max_connection passa à dar esse erro aqui: >>> >>> 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 >>> >>> Se procurar no google por esse erro vamos ver que muita gente tenta >>> resolver isso mas tudo que li e tentei não consegui resolver. Só >>> descobri que se tento usar os 4000 começa à dar os erros de acesso >>> que postei acima. >>> >>> Aí mais à frente descobri essa página: >>> >>> http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html >>> >>> Onde no final está escrito assim: >>> >>> The maximum number of connections MySQL can support depends on the >>> quality of the thread library on a given platform. Linux or Solaris >>> should be able to support 500-1000 simultaneous connections, >>> depending on how much RAM you have and what your clients are doing. >>> Static Linux binaries provided by MySQL AB can support up to 4000 >>> connections. >> Lendo esse parágrafo me faz pensar da seguinte maneira: >> >> Otimização no código para ambiente Linux >> >> >> Uma vez que eles fornecem os binários já compilados prontos para >> instalar. Isso me faz recordar uma discução antiga sobre a venda da sum >> para a Oracle ..... como você usa apenas MYISAM, tente uma versão anterior >> a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique >> se há essa diferença gritante... sei lá é apenas uma teoria da conspiração >> >> >> flames > /dev/null >> >> PS.: >> Já tentopu rodar o mesmo binário na emulação Linux no free, como já >> disseram antes???? >> >> >> -- >> Nilton José Rizzo >> 805 Informatica >> Disseminando tecnologias >> 021 2413 9786 >> --- >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> >> http://en.wikipedia.org/wiki/Posting_style >> >> ------------------------- >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
