Em 13/07/2012 15:04, NullCk escreveu: > 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
Opa Thiago com certeza. O que o Patrick levantou foi que aquela variável em questão read_rnd_buffer_size associada ao max_conn não deveria exigir muita ram. Pelo menos foi isso que entendi. :) > > > 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 <[email protected]> escreveu: > > De: Marcelo Gondim <[email protected]> > 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)"" > <[email protected]> > 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 > ------------------------- > 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
