[FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD

[Marcelo Gondim]

Em 11/07/2012 17:18, Luiz Otavio O Souza escreveu:
> 2012/7/11 Antônio Pessoa <atnpessoa em gmail.com>:
>> 2012/7/11 Luiz Otavio O Souza <lists.br em 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 é. :)