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

Sexta Julho 13 15:04:53 BRT 2012

Veja só  esse valor de 4000 conexões é um valor muito alto para o MySQL lidar, 

O número de conexões deve ser definido tendo em vista  a quantidade de memória RAM que se tem.

http://dev.mysql.com/doc/refman/5.0/en/too-many-connections.html

Thiago Dias aka nullck
Powered By Linux
LPIC 1| Novell CLA | ITILv3
Linux For Servers
Macintosh For Graphics
Windows For Play Solitaire

--- Em sex, 13/7/12, Marcelo Gondim <gondim em bsdinfo.com.br> escreveu:

De: Marcelo Gondim <gondim em bsdinfo.com.br>
Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Para: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <freebsd em fug.com.br>
Data: Sexta-feira, 13 de Julho de 2012, 14:28

Em 13/07/2012 13:41, Marcelo Gondim escreveu:
> Em 13/07/2012 13:33, Patrick Tracanelli escreveu:
>> Em 13/07/2012, às 13:26, Marcelo Gondim escreveu:
>>
>>> Em 13/07/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:
>>> Opa Patrick pelo que vimos o mesmo ocorre tanto no Linux quanto no
>>> FreeBSD. No linux tava funcionando porque lá não tinha definido o
>>> read_rnd_buffer_size e pelo jeito quando não está definido o valor deve
>>> ser bem baixo. Mas como peguei o my-huge.cnf, alterei as confs que eu já
>>> tinha no outro mysql do Linux e não vi que a read_rnd_buffer_size estava
>>> lá com 8M quando re-iniciei o mysql tomei um susto ao ver o
>>> tuning-primer rsrsrsr
>>>
>>>> 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.
>>> Esse cara não tá definido no .cnf deve estar usando o valor default dele.
>>>
>>>> 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.
>>> Bem aí não sei te dizer mas é isso mesmo que ocorre. Pra ver isso é só
>>> copiar o my-huge.cnf e adicionar o max_connections = 4000 que vai
>>> acontecer isso mesmo, vai dizer que precisa de muita ram. Aí você
>>> comenta o read_rnd_buffer_size e volta ao normal.
>>>
>>>> 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?
>>> Peguei agora aqui uma VM com freebsd 9 amd64 e está com mysql 5.1.
>>> Copiei o my-huge.cnf sem fazer nenhuma mudança. O resultado:
>>>
>>> MEMORY USAGE
>>> Max Memory Ever Allocated : 438 M
>>> Configured Max Per-thread Buffers : 1.82 G
>>> Configured Max Global Buffers : 426 M
>>> Configured Max Memory Limit : 2.24 G
>>> Physical Memory : 1023 M
>>>
>>> Max memory limit exceeds 90% of physical memory
>>>
>>> Agora a mesma conf colocando max_connections = 4000
>>>
>>> MEMORY USAGE
>>> Max Memory Ever Allocated : 438 M
>>> Configured Max Per-thread Buffers : 48.46 G
>>> Configured Max Global Buffers : 426 M
>>> Configured Max Memory Limit : 48.87 G
>>> Physical Memory : 1023 M
>>>
>>> Max memory limit exceeds 90% of physical memory
>> Cara biiizonho, ta ai é bixeira no MySQL então.
>>
>> Ou mudou algo que eu não acompanhei se esse comportamento for esperado, pq como eu disse aqui em um 5.0 tem o tripo de max conn e read_rnd_buffer_size em 4M, aloca o 4M*num_threads ativas.
> Pois é, aí se eu tiro ou comento  o read_rnd_buffer_size fica normal.
> Vou instalar o MySQL 5.0 aqui e fazer a mesma coisa. Já posto aqui o
> resultado.
>
>
Patrick, instalei o MySQL 5.0, coloquei lá o my-huge.cnf como my.cnf, 
adicionei o max_connections = 4000 e deram os mesmos valores:

MEMORY USAGE
Max Memory Ever Allocated : 438 M
Configured Max Per-thread Buffers : 48.46 G
Configured Max Global Buffers : 426 M
Configured Max Memory Limit : 48.87 G
Physical Memory : 1023 M

Max memory limit exceeds 90% of physical memory

Quando comento o read_rnd_buffer_size mantendo as 4000 conexões fica assim:

MEMORY USAGE
Max Memory Ever Allocated : 430 M
Configured Max Per-thread Buffers : 18.18 G
Configured Max Global Buffers : 426 M
Configured Max Memory Limit : 18.60 G
Physical Memory : 1023 M

Max memory limit exceeds 90% of physical memory

Aproveitando Patrick, é verdade que o 8.3 está realmente com mais 
performance que o 9.0? Essa variação de load entre uma e outra é causada 
por essa diferença de performance?

-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd