2012/7/9 Luiz Gustavo S. Costa <[email protected]>: > Em 9 de julho de 2012 14:32, Matheus Weber da Conceição > <[email protected]> escreveu: >> Em 9 de julho de 2012 14:15, Marcelo Gondim <[email protected]>escreveu: >> >>> Em 09/07/2012 12:52, Francisco Cardoso escreveu: >>> > Em 9 de julho de 2012 10:42, Marcelo Gondim <[email protected]> >>> 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... ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
