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

Sexta Julho 13 12:37:43 BRT 2012

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
> 316601 em 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.