[FUG-BR] Servidor com load altíssimo

Segunda Julho 9 15:18:12 BRT 2012

Em 09/07/2012 15:06, William Grzybowski escreveu:
> 2012/7/9 Luiz Gustavo S. Costa <luizgustavo em luizgustavo.pro.br>:
>> Em 9 de julho de 2012 14:32, Matheus Weber da Conceição
>> <matheuswcon em gmail.com> escreveu:
>>> Em 9 de julho de 2012 14:15, Marcelo Gondim <gondim em bsdinfo.com.br>escreveu:
>>>
>>>> Em 09/07/2012 12:52, Francisco Cardoso escreveu:
>>>>> Em 9 de julho de 2012 10:42, Marcelo Gondim <gondim em bsdinfo.com.br>
>>>> escreveu:
>>>>>> Em 08/07/2012 11:36, Leonardo Augusto escreveu:
>>>>>>> Bom Marcelo,
>>>>>>>
>>>>>>> Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects
>>>>>>> contra 700 inserts... entao nao sei se foi com ou sem o tal anounce
>>>>>>> rodando, mas tem bem mais select que insert.
>>>>>> Tava sem announce rsrsrs o announce arregaça tudo ahahha
>>>>>>
>>>>>>> O que ja vi tambem, é que esse sistema é um sistema opensource, ja
>>>>>>> baixei ele pra dar uma olhada, vi que no index tem um select
>>>>>>> sinistro la, que o memcache ajudaria muito.
>>>>>> É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian
>>>>>> lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que
>>>> nada.
>>>>>> Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar
>>>>>> tudo com calma agora.  :D
>>>>>>
>>>>>>> MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, KKKK
>>>>>>>
>>>>>>> teu "programador" php ta relutante a usar o memcache, pq NAO FOI ele
>>>>>>> que desenvolveu esse sistema e por o memcache ali da um pouco
>>>>>>> de trabalho, pois tem que entender/alterar a classe de acesso ao
>>>>>>> mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a
>>>>>>> crua...
>>>>>>> o que é ridiculo, quando deveria ser uma classe responsavel por isso,
>>>>>>> para justamente nao ter que correr o sistema todo para alterar
>>>>>>> qualquer
>>>>>>> comportamento do mysql.
>>>>>>> O fato é esse, o magrao do php ta mais perdido que cusco no meio de
>>>>>>> procissao, kkk
>>>>>> ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar
>>>>>> uns e-mails pvt.
>>>>>>
>>>>>>
>>>>>>> Uma duvida que tenho que faz muita diferenca é a seguinte:
>>>>>>>
>>>>>>> - esse sistema é acessado(alguma url dele) pelos clientes de torrent ?
>>>>>>> por exemplo, se peguei um link dum torrent do teu site
>>>>>>> e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o
>>>>>>> microtorrent ele por si só acessa o site ? ou o proprio
>>>>>>> site que usa o anounce quando eu clico num link do mesmo ?
>>>>>>> resumindo: algum agente externo(cliente de torrent) atualiza algo no
>>>>>>> site, ou tudo acontece a partir dos clicks no site ?
>>>>>> O problema são o número de conexões ao mysql que chega à 4000. Tipo
>>>>>> vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que
>>>>>> você pára um torrent, inicia, termina de baixar e fica de seeder, começa
>>>>>> à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando
>>>>>> uma passkey tua, e faz a atualização na base de dados, update, insert,
>>>>>> essas coisas pra atualizar as informações sobre o que você tá fazendo. É
>>>>>> assim por exemplo que o seu ratio sobe ou desce, porque em sites de
>>>>>> torrent fechados você não pode ter ratio baixo porque senão você é
>>>>>> banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso.
>>>>>> rsrsrsr é muita conexão concorrente na base. Tudo com update, insert,
>>>>>> etc  :)
>>>>>>
>>>>>> Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000
>>>>>> conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco
>>>>>> 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram.
>>>>>> Vi outros relatos sobre isso também na minha pesquisa, pessoas
>>>>>> reclamando do mysql no freebsd quando a carga é alta.
>>>>>>
>>>>> Prezado Marcelo:
>>>>>
>>>>> Poderia nos colocar a par das suas fontes de pesquisa comprovando o
>>>>> problema do Mysql no FreeBSD? Acho que seria importante para
>>>>> documentarmos o fato bem como para podermos procurar uma solução.
>>>>> Lembro que há alguns anos atrás um cara do Yahoo documentou um
>>>>> problema semelhante e teve uns caras depois que colocaram para
>>>>> funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a
>>>>> implementação do linuxthreads, se não me falha a memória.
>>>> Sim mas o linuxthreads está marcado como não compilável mais no ports.
>>>> Tentei compilar o mysql com ele pra testar mas não deixou.
>>>>
>>>> http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html
>>>>
>>>> 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.
>>>>
>>>>> Depois a implementação de threads do FreeBSD mudou. Acho que na época
>>>>> do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava
>>>>> até melhor no Free que no Linux.
>>>> Pois é até agora não entendi isso como que no Linux a coisa funciona de
>>>> cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no
>>>> hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o
>>>> cd Debian e refiz a Instalação.
>>>> Pra ter uma idéia da situação: o site sem o announce liberado e sem
>>>> liberação para os usuários. Somente eu e mais 2 pessoas da administração
>>>> online... quando eu fazia uma consulta de torrent ficava bem lento.
>>>> Poderia ser o ZFS?
>>>>
>>>>> Além disso deve haver pessoas que tem concorrência brutal de MySQL no
>>>>> Free, também não me conformo de não ter dado certo ... :-( . Acho que
>>>>> podemos fazer o seguinte:
>>>>>
>>>>> 1 - Nos torne a par das suas fontes que relatam o problema de
>>>>> concorrência para ver se ajudamos;
>>>> Essa aqui foi uma que achei das mais interessantes:
>>>> http://forums.freebsd.org/showthread.php?t=18943
>>>>
>>>>> 2 - Como montaríamos um ambiente offline para simularmos o caso sem
>>>>> ter que fazer uma atividade tão corrida como foi essa sua agora?
>>>> Pois é o site vive de doações e normalmente o que conseguimos à mais
>>>> investimos no próprio servidor e até em uma máquina de testes.
>>>> Espero que em breve tenhamos uma outra máquina boa pra testes no
>>>> Datacenter.
>>>>
>>>>> 3 - Acho que a documentação da época do Free 7 dizia os parâmetros de
>>>>> tuning. Talvez ajude mas, acho que o correto seria simular este seu
>>>>> ambiente ...
>>>>>
>>>>> Abraços e parabéns pelo esforço!
>>>>>
>>>> Obrigado mas ainda quero ver esse site no Freeba rodando igual ou melhor
>>>> que no Linux.  :)
>>>>
>>>> -------------------------
>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>
>>> Buenas;
>>>
>>> Acho que vale um teste com FreeBSD 9 com UFS e FreeBSD 8.3 com UFS heim!!!
>>> Vai que é o ZFS dando zica...
>>>
>>>
>>> --
>>> ============================
>>> Matheus Weber da Conceição
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> ZFS dando zica ?!?!
>>
>> pow.. tenho sistemas rodando com cacetada de coisas e nunca tive zica
>> nenhuma, pelo o contrario !
>>
>> se tiver alguma zica, pode olhar os i/o' que são as unicas coisas que
>> podem dar "zica":
>>
>> # zpool iostat
>> # gstat
> Agora que você falou isso veio uma coisa em mente...
> Rodar ZFS em sistemas onde o userland precisa de muita memória pode
> ser um grande problema.
> Por padrão o ZFS pode usar até 80% da memória... deixando as
> aplicações de userland morrendo de fome.
>
> Seria intressante capar o zfs setando o arc_max e o kmem_size...

HaHaHaha puts se foi isso só me matando ahahahah

Outra coisa muito interessante:

No FreeBSD, quando eu colocava as 4000 conexões no my.cnf e rodava o 
tuning-primer.sh o mesmo dizia que eu estava estourando a memória e que 
precisa de 70Gb de ram pelo menos.
Quando fiz a mesma coisa no Debian com as 4000 conexões e rodei o 
tuning-primer.sh o mesmo estava normal e sem alto consumo de memória:

MEMORY USAGE
Max Memory Ever Allocated : 7.05 G
Configured Max Per-thread Buffers : 11.71 G
Configured Max Global Buffers : 650 M
Configured Max Memory Limit : 12.35 G
Physical Memory : 23.53 G
Max memory limit seem to be within acceptable norms

Esses dados acima no FreeBSD com 4000 conexões de my.cnf nossa mãe que 
estourava tudo e mostrava o Configured Max Memory Limit : com tipo uns 70G.