Em 09/07/2012 15:06, William Grzybowski escreveu: > 2012/7/9 Luiz Gustavo S. Costa <luizgust...@luizgustavo.pro.br>: >> Em 9 de julho de 2012 14:32, Matheus Weber da Conceição >> <matheusw...@gmail.com> escreveu: >>> Em 9 de julho de 2012 14:15, Marcelo Gondim <gon...@bsdinfo.com.br>escreveu: >>> >>>> Em 09/07/2012 12:52, Francisco Cardoso escreveu: >>>>> Em 9 de julho de 2012 10:42, Marcelo Gondim <gon...@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. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd