Em 11/07/2012 17:18, Luiz Otavio O Souza escreveu: > 2012/7/11 Antônio Pessoa <atnpes...@gmail.com>: >> 2012/7/11 Luiz Otavio O Souza <lists...@gmail.com> >>> >>> Marcelo, >>> >>> Use o mesmo my.cnf nos dois servidores pois são as configurações que >>> estão lá que determinam quanto cada thread (ou conexão) vai consumir. >>> >>> Att., >>> Luiz >> >> Ele já fez isso. >> > çey =) > > > # The MySQL server > [mysqld] > bind-address = 127.0.0.1 > port = 3306 > socket = /tmp/mysql.sock > skip-locking > key_buffer = 16K > max_allowed_packet = 1M > table_cache = 4 > sort_buffer_size = 64K > read_buffer_size = 256K > read_rnd_buffer_size = 256K > net_buffer_length = 2K > thread_stack = 64K > skip-innodb > #skip-networking > server-id = 1 > max_connection = 4000 > > > > MEMORY USAGE > Max Memory Ever Allocated : 1 M > Configured Max Per-thread Buffers : 3.17 G > Configured Max Global Buffers : 16 K > Configured Max Memory Limit : 3.17 G > Physical Memory : 1.99 G > > Max memory limit exceeds 90% of physical memory > > > Claro que estoura o limite to meu pequeno servidor, mas com 12G ainda > sobra algum espaço pra brincar.
O problema é que mesmo com 12Gb não sobra espaço. :) Se você fizer isso que você fez aí em um Linux, bem eu fiz num Debian, vai ver que vai sobrar muito mais que isso. rsrsrs Você pode pegar a mesma conf aí em cima e socar nele que você vai ver. > > Agora a pergunta é, seu servidor realmente precisa aceitar 4000 > conexões simultaneas ? não convém dividir uma carga dessas ? Não tem jeito. Faz idéia de um site de torrents fechado e grande? :) Nosso site tem quase 100mil users, mais de 400mil peers e pra lá de 70mil torrents. Imagina uma pessoa compartilhando 30 torrents, isso por baixo. Quando esse cara abre o cliente de torrent dele, o mesmo conecta no site através do announce que faz uma série de updates e inserts na base de cada torrent dele que tem uma passkey dele. Agora você imagina a quantidade de gente fazendo esse acesso e mais ainda os acessos normais ao site. Se fossem só selects o memcache faria a mágica. Hoje graças ao Leonardo com a idéia do memcache o site está muito mas muito mais rápido nas consultas porque implementamos o memcache mas os announces castigam a gente rsrsrsr. Tudo começou comigo tentando migrar o site para o FreeBSD, onde primeiramente peguei a mesma conf, o mesmo my.cnf e não rolava. No servidor antigo que era uma máquina bem inferior com apenas 16Gb de ram rodava bem, já no novo com 24Gb de ram e usando a mesma conf dizia que não tinha ram suficiente. Foi aí que começou toda a bagaça. :) O restante só lendo a thread ahahah pq é muita coisa. rsrsrsrsr > > Isso é puramente uma questão de configuração do MySQL e não tem > relação com o SO (FreeBSD). Também achava isso na minha cabeça. Agora me explica então como na mesma máquina usando a mesma conf do mysql, obtive valores diferentes em SOs diferentes? Porque o que fiz apenas foi formatar a máquina, colocar o Debian, usar a mesma conf do mysql e pronto. No caso do freebsd além de informar um alto uso de ram com a mesma configuração do mysql, quando aumentava o uso das conexões já apresentava um erro de falta de memória. Também quero encontrar uma solução para esse problema mas dizer que é apenas conf do mysql... isso tenho certeza, hoje, que não é. :) ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd