[FUG-BR] Servidor com load altíssimo

Segunda Julho 9 16:32:21 BRT 2012

Em 09/07/2012 15:36, Saul Figueiredo escreveu:
> Em 9 de julho de 2012 15:09, Marcelo Gondim <gondim em bsdinfo.com.br>escreveu:
>
>> Em 09/07/2012 14:55, Luiz Gustavo S. Costa escreveu:
>>> 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
>>>
>> rsrsrs foi só uma idéia mas também não acredito que fosse ele em si. Mas
>> que no FreeBSD 8.3-stable ficou melhor que no 9-stable isso ficou. Por
>> que será?
>> Será que no 9.1 esses problemas de performance vão estar resolvidos ou
>> só veremos isso lá pelo 9.2 ou 9.3? Fica a dúvida.
>>
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>
> Nada Godin... parece que eles estão focando em outras coisas. Esse "pau"
> por exemplo, continua, e tem outros relacionados com interface gráfica que
> eles estão trabalhando... tem isso no forum americano mais detalhado, vou
> ver se acho e envio...
>
Pessoal acabei receber uma ajuda que poderia ser o motivo, mas estranho 
é que nenhuma mensagem apareceu no dmesg. Bem executando o comando 
abaixo no Debian com o site no ar e todo mundo acessando com announce, 
tudo bonitinho, mais de 3300 usuários conectados no site:

# mysql -u root -p -e 'SHOW STATUS' | grep '^Open'
Enter password:
Open_files      45
Open_streams    0
Open_table_definitions  99
Open_tables     241
Opened_files    7389857
Opened_table_definitions        0
Opened_tables   0

# mysql -u root -p -e 'SHOW GLOBAL VARIABLES' | grep 'open_files_limit'
Enter password:
open_files_limit        20000

Olhem quantos arquivos abertos e tenho quase certeza que o os meus 
parâmetros estavam assim:

kern.maxfiles: 256000
kern.maxfilesperproc: 256000

Se eu estiver errado me corrijam mas puts 256000 não ia dar nem pro 
cheiro dos 7389857. Poderia ser esse o motivo da lentidão?