Em 13/07/2012 13:33, Patrick Tracanelli escreveu: > Em 13/07/2012, às 13:26, Marcelo Gondim escreveu: > >> Em 13/07/2012 12:30, Patrick Tracanelli escreveu: >>> Em 13/07/2012, às 12:00, Marcelo Gondim escreveu: >>> >>>> 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 >>> Gondim, >>> >>> Só agora consegui ler essa thread que não peguei desde o início: que opera >>> hein? >>> >>> Bom de qualquer forma pra mim isso é um bug. Só não sei onde, mas isso é um >>> bug, ou do MySQL ou do MySQL no FreeBSD 9.0. >>> >>> Eu não pude ver direito ao certo se voce testou exatamente o mesmo my.cnf >>> no Linux, FreeBSD 8 e FreeBSD 9, aparentemente sim, e o bug só aconteceu no >>> 9 correto? Tem que comparar versão do MySQL q tinha no 9 e no 8 pra tirar a >>> limpo de quem é o bug mas o read_rnd_buffer_size nesse valor pra esse >>> número de sessões... estranho estourar, pior ainda gerar uma reserva de 32G >>> de RAM pra isso. O uso dessas 3 variaveis tem que ser combinadas, >>> especialmente o max_lenght: >> Opa Patrick pelo que vimos o mesmo ocorre tanto no Linux quanto no >> FreeBSD. No linux tava funcionando porque lá não tinha definido o >> read_rnd_buffer_size e pelo jeito quando não está definido o valor deve >> ser bem baixo. Mas como peguei o my-huge.cnf, alterei as confs que eu já >> tinha no outro mysql do Linux e não vi que a read_rnd_buffer_size estava >> lá com 8M quando re-iniciei o mysql tomei um susto ao ver o >> tuning-primer rsrsrsr >> >>> sort_buffer_size >>> max_length_for_sort_data >>> read_rnd_buffer_size >>> >>> Ou seja seu max_lenght_for_sort_data ou está alto demais ou seu banco tem >>> umas queries "order by/group by/sort" alienígenas ao ponto de rapidamnete >>> popularem todo o buffer. >> Esse cara não tá definido no .cnf deve estar usando o valor default dele. >> >>> De qualquer forma, pelo jeito que o read_rnd_buffer_size funciona, fazendo >>> cache de ponteiro de memória crú na primeira vez que a pilha é ordenada, é >>> fácil ter algum bug em algum momento. Afinal ponteiro de memória só não é >>> mais delicado que ponteiro de ponteiro hehehe. >>> >>> Outra coisa é que a alocação desse buffer deve ser multiplicada pra cada >>> thread, e não pra cada conexão. Mas um indício que se temos >>> read_rnd_buffer_size * max_connections alocando memória temos um belo bug. >> Bem aí não sei te dizer mas é isso mesmo que ocorre. Pra ver isso é só >> copiar o my-huge.cnf e adicionar o max_connections = 4000 que vai >> acontecer isso mesmo, vai dizer que precisa de muita ram. Aí você >> comenta o read_rnd_buffer_size e volta ao normal. >> >>> Eu tenho aqui um com 12k max_conn e read_rnd_buffer_size em 4M que não é 8M >>> mas a mera multiplicação deveria aloprar a maquina que tem so 12G de RAM. >>> No entanto nesse momento por exemplo o show full processlist mostra 2.100 >>> conexões e o consumo de memoria é esse aqui: >>> >>> 43464 mysql 61 20 0 1631M 1395M uwait 6 39.9H 0.12% mysqld >>> >>> Ou seja 1.6G e apenas 61 threads então ou tem outro fator ferrando esse >>> tuning ou é um bug em algum lugar. >>> >>> Voce pode me responder quais eram as versões de MySQL em cada sistema? >> Peguei agora aqui uma VM com freebsd 9 amd64 e está com mysql 5.1. >> Copiei o my-huge.cnf sem fazer nenhuma mudança. O resultado: >> >> MEMORY USAGE >> Max Memory Ever Allocated : 438 M >> Configured Max Per-thread Buffers : 1.82 G >> Configured Max Global Buffers : 426 M >> Configured Max Memory Limit : 2.24 G >> Physical Memory : 1023 M >> >> Max memory limit exceeds 90% of physical memory >> >> Agora a mesma conf colocando max_connections = 4000 >> >> MEMORY USAGE >> Max Memory Ever Allocated : 438 M >> Configured Max Per-thread Buffers : 48.46 G >> Configured Max Global Buffers : 426 M >> Configured Max Memory Limit : 48.87 G >> Physical Memory : 1023 M >> >> Max memory limit exceeds 90% of physical memory > > Cara biiizonho, ta ai é bixeira no MySQL então. > > Ou mudou algo que eu não acompanhei se esse comportamento for esperado, pq > como eu disse aqui em um 5.0 tem o tripo de max conn e read_rnd_buffer_size > em 4M, aloca o 4M*num_threads ativas.
Pois é, aí se eu tiro ou comento o read_rnd_buffer_size fica normal. Vou instalar o MySQL 5.0 aqui e fazer a mesma coisa. Já posto aqui o resultado. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd