[FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD

[Marcelo Gondim]

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 <rizzo em 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 <gondim em 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
>
>