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

[Marcelo Gondim]

Evento: migração de um servidor de torrents de um Datacenter na Holanda 
para um Datacenter na Rússia.

Holanda:
Equipamento: 2x4 Core Xeon L5410 2.33GHz 16Gb de ram 2 discos SAS de 72Gb.
SO: Debian 6.0 amd64
Programas: Apache 2.2.16 + PHP 5.3 + MySQL 5.1 - mais conhecido como 
LAMP rsrsrsr

Rússia:
Equipamento: 2x6 Core Xeon E5645 2.4Ghz 24Gb de ram 4 discos SAS de 
147Gb 15k rpm em raid 0

1ª tentativa:
SO: FreeBSD 9.0-Stable amd64
Programas: Apache 2.2.22 +  PHP 5.3 + MySQL 5.1 (BUILD_OPTIMIZED) - FAMP? :D

Nessa tentativa eu reparei ao iniciar a aplicação loads muito altos na 
casa de 200 e cheguei à ver 1000. Também estava tendo problemas com o 
MySQL porque ao pegar o my-huge.cnf e alterar ele com os valores que eu 
já tinha no servidor antigo me deparei com o consumo de ram muito alto. 
Na aplicação web me gerava o seguinte erro quando chegava em umas 3000 
conexões na base MySQL:

DATABASE: mysql_connect: Can't create a new thread (errno 35); if you
are not out of available memory, you can consult the manual for a
possible OS-dependent bug

Utilizei o tuning-primer pra ver os valores que estavam sendo usados e o 
que estava sendo consumido.

2ª tentativa:
Em dado momento algumas pessoas me sugeriram usar o FreeBSD 8.3 por 
estar com uma performance melhor que o 9. Aí fiz todos os procedimentos 
abaixo passando o sistema de FreeBSD 9-stable para o 8.3-stable:

- alterei o supfile de RELENG_9 para RELENG_8.
- fiz o csup nele.
- fiz o buildword e buildkernel
- fiz installkernel e installworld
- mergemaster, delete-old e delete-old-libs
- reboot na criança
- recompilei todos os pacotes instalados com o portmaster -a -f

O load do sistema já melhorou absurdamente e passou à ficar na casa dos 
1.x, 10.x mas nada com 3 casas rsrsrs  Não sei se houve alguma mudança 
nisso entre o 8.3 e o 9.
Mas o MySQL continuava estranho e como já estávamos alguns dias parados 
resolvemos voltar para o Linux.

Resultado final:
O problema do MySQL era a variável "read_rnd_buffer_size" que veio do 
my-huge.cnf e que o default dela é 8M. Tudo bem usar ela como default 
desde que você use o max_connections com valores baixos. O default do 
max_connections, se eu não me engano, é 150. Quando colocava o 
max_connections com 4000 o mysql avisava que ia precisar de uns 48G de 
ram pra trabalhar nessa quantidade e aí quando chegava em 2000 à 3000 
conexões concorrentes já dava erro de falta de memória no MySQL.
O que resolveu foi simplesmente comentar essa variável e tunnar as 
outras para as minhas necessidades e ficou 100%

Pena que agora só poderemos tentar colocar o FreeBSD mais pra frente mas 
desta vez farei diferente algumas coisas:

1º Usarei RAID 10.
2º Sistema de arquivos UFS2+SUJ porque o ZFS consome muita memória, 
embora seja possível controlar isso, mas acredito que o UFS2+SUJ fique 
melhor.
3º Tunning melhor do sistema no sysctl, loader e kernel.

Acho que é isso pessoal.

Gondim