Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
ta legal isso, o negocio é que nao esta no bsd o problema, ainda bem. podes passar esses hosts holanda e russia pra eu ver os valores? toda essa questao do mysql provem de usar myisam, essa var citada é só pro myisam certo? pq nao faz um teste com innodb, será que daria isso tb? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Não ficou não tá rodando sem ele normalmente. :D - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo, Você disse que o load estava altíssimo no FreeBSD 9.0 usando um determinado my.cnf e que com esse mesmo arquivo num FreeBSD 8.3 o load ficava bem menor. É isso mesmo? -- Celso Vianna BSD User: 51318 http://www.bsdcounter.org 63 8404-8559 Palmas/TO - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 13/07/2012 10:02, Celso Viana escreveu: Não ficou não tá rodando sem ele normalmente. :D - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo, Você disse que o load estava altíssimo no FreeBSD 9.0 usando um determinado my.cnf e que com esse mesmo arquivo num FreeBSD 8.3 o load ficava bem menor. É isso mesmo? Sim o load foi outra questão interessante. Eu levantei o site e liguei o tracker (announce.php). O load ficava na casa dos 200 caía pra 70, 25 subia e descia. Aí fiz o downgrade do 9-stable para o 8.3-stable. Como fiz isso? - 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 Só em fazer isso o load passou à ficar em 3, 10, 1. e até 0. algumas vezes. Houve realmente uma melhora. Teve mudança nessa parte de load entre o 8.3 e o 9? Mas tipo mesmo com o load alto o maior problema era o MySQL que já descobrimos o que era. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
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: 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. 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. 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 200 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? --
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Em 13/7/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: 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. 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. 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 200 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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Em 13/07/2012 12:37, Paulo Henrique BSD Brasil escreveu: Em 13/7/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: 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. 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. 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 200 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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Em 13/07/2012 13:41, Marcelo Gondim escreveu: 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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Veja só esse valor de 4000 conexões é um valor muito alto para o MySQL lidar, O número de conexões deve ser definido tendo em vista a quantidade de memória RAM que se tem. http://dev.mysql.com/doc/refman/5.0/en/too-many-connections.html Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em sex, 13/7/12, Marcelo Gondim gon...@bsdinfo.com.br escreveu: De: Marcelo Gondim gon...@bsdinfo.com.br Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Sexta-feira, 13 de Julho de 2012, 14:28 Em 13/07/2012 13:41, Marcelo Gondim escreveu: 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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA]
Em 13/07/2012 15:04, NullCk escreveu: Veja só esse valor de 4000 conexões é um valor muito alto para o MySQL lidar, O número de conexões deve ser definido tendo em vista a quantidade de memória RAM que se tem. http://dev.mysql.com/doc/refman/5.0/en/too-many-connections.html Opa Thiago com certeza. O que o Patrick levantou foi que aquela variável em questão read_rnd_buffer_size associada ao max_conn não deveria exigir muita ram. Pelo menos foi isso que entendi. :) Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em sex, 13/7/12, Marcelo Gondim gon...@bsdinfo.com.br escreveu: De: Marcelo Gondim gon...@bsdinfo.com.br Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESUMO] [RESOLVIDA] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Sexta-feira, 13 de Julho de 2012, 14:28 Em 13/07/2012 13:41, Marcelo Gondim escreveu: 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á
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12 de julho de 2012 01:40, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Tranquilo :) Ainda bem que esclarecemos o mistério rs [ ]'s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
bah pega a 12 e faz o cla-cla bum que nem eu disse, afee maria que coisa hein. ainda bem que foi problema de BIOS (bixo idiota operando o sistema) k bah marcelo, isso acontece, mas ajuda a pessoa a ter mais atencao nos detalhes, daqui pra frente tenho certeza que vais ficar mais atento nos copy/paste da vida se vc tunar o freebsd, vai por o linSux debaixo do chinelo pra vc ter ideia, tenho uns amigos que tem um site de lista de email, um dos maiores se nao o, do brasil, eles comecaram com linux... chegou uma hora que nem ssh vc conseguia fazer... nao respondia, altissimo load, iam trocar de hardware... aí migraram pro freebsd e nem precisaram mudar de hardware... mesmo com 200% de load conseguiam fazer ssh normal e tudo funcionava, nada travava a vm e a pilha tcp do freebsd sao imbativeis, com alto load de verdade( swap sei la em 60¨% ) o freebsd continua respondendo e o linux faz igual o pinguim, congela... kkk sempre li e vi casos relatando isso... em alta carga o linux se perde todo, o windows 2008 se nao me engano copiou o esquema da pilha tcp do freebsd, por isso que funciona um pouco melhor que os antecessores.. na ultima copa da alemanha,TODA infra de rede da copa la, foi baseada em freebsd... pq sera ? olha o uptime dessa minha maquina: 9:07AM up 1268 days, 17:28, 1 user, load averages: 0.13, 0.13, 0.08 e tem acesso pra cararmba, em media 18G por mes de trafego, tudo mysql AGORA ARRANCA LOGO ESSE LINUX E VOLTA PRO FREEBSD, EHEHE quem bom que foi constatado o problema, agora volta pro freebsd para poder dormir tranquilo, tirar ferias, ir pra balada, e esquecer que tem um server pra cuidar, ehe seria interessante vc enviar um email finalizando o problema com todos detalhes que testou e as configuracoes finais que funcionaram. resgatar todas as partes da thread fica meio complicado, amanha aparece outro com o mesmo problema. abraco p.s e viu como o Brandi é o cara, eheh - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Pegando carona na thread, alguém já usando o mariadb ? alguma diferença ? vale a pena migrar para a dona Maria ? Pra quem não conhece: [lgcosta@desktop] ~ cat /usr/ports/databases/mariadb-server/pkg-descr MariaDB is a database server that offers drop-in replacement functionality for MySQL1. MariaDB is built by some of the original authors of MySQL, with assistance from the broader community of Free and open source software developers. In addition to the core functionality of MySQL, MariaDB offers a rich set of feature enhancements including alternate storage engines, server optimizations, and patches. MariaDB is primarily driven by developers at Monty Program, a company founded by Michael Monty Widenius, the original author of MySQL, but this is not the whole story about MariaDB. On the About MariaDB page you will find more information about all participants in the MariaDB community, including storage engines XtraDB and PBXT. WWW: http://mariadb.org/ -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. -- http://about.me/paulocavalcanti - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12 de julho de 2012 01:40, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 12/07/2012 00:24, Edson Brandi escreveu: Marcelo, O problema está nessa configuração ai do mysql que vc esta usando... Refiz um teste aqui com o FreeBSD 64 bits... Se eu uso o /usr/local/share/mysql/my-huge.cnf como sendo o meu /var/db/mysql/my.cnf e seto o max_connections=4000 , o output do tunning primer é o que vc está obtendo: MEMORY USAGE Max Memory Ever Allocated : 572 M Configured Max Per-thread Buffers : 48.21 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 48.76 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Se eu uso o mysqld com a configuração default (default = não existe o my.cnf), e adiciono apenas o parâmetro para 4.000 conexões (o arquivo vai ficar com apenas 2 linhas): [mysqld] max_connections=4000 O output do tuning-primer.sh é o que eu tinha enviado antes (muito semelhante no linux e no FreeBSD): MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 3.74G Max memory limit exceeds 90% of physical memory Se eu uso o mesmo arquivo de configuração (/usr/local/share/mysql/my-huge.cnf ) no servidor Linux, fazendo os ajustes necessários para que o mysqld rode, visto que aqui no meu lab o daemon no linux nem sobe com este arquivo de configuração copiado do FreeBSD se vc não adicionar as linhas abaixo na sessão [mysqld]: datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql O resultado é o mesmo que no FreeBSD: MEMORY USAGE Max Memory Ever Allocated : 584 M Configured Max Per-thread Buffers : 48.46 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 49.00 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Ou seja, acho pouco provável que o seu servidor Linux e o seu servidor FreeBSD estejam rodando exatamente com a mesma configuração no MySQL (este my-huge.cnf)... Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Já fiz algo parecido as 2 da madrugada depois de mais de 20 horas trabalhando direto. Só descobri la para as 6 da matina quando nao tinha mas esperança e o café tinha acabado. -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 09:21, Leonardo Augusto escreveu: bah pega a 12 e faz o cla-cla bum que nem eu disse, afee maria que coisa hein. Pois é rsrsrs ainda bem que foi problema de BIOS (bixo idiota operando o sistema) k Põe bios nisso fdp de um k que virou m ahahahahahah bah marcelo, isso acontece, mas ajuda a pessoa a ter mais atencao nos detalhes, daqui pra frente tenho certeza que vais ficar mais atento nos copy/paste da vida se vc tunar o freebsd, vai por o linSux debaixo do chinelo Eu acredito nisso ehehehh já fiz isso com todos os servidores Linux que eu tinha. Esse servidor já estava um tempo tentando fazer isso, mas o antigo sysadmin estava sem tempo e queria acompanhar isso. Como ele saiu da equipe por causa da faculdade acabei que fiquei de frente no core team rsrsr Como tínhamos que mudar de Datacenter por causa dos processos por sermos um Servidor de Torrents, aproveitei para tentar migrar para o FreeBSD. pra vc ter ideia, tenho uns amigos que tem um site de lista de email, um dos maiores se nao o, do brasil, eles comecaram com linux... chegou uma hora que nem ssh vc conseguia fazer... nao respondia, altissimo load, iam trocar de hardware... aí migraram pro freebsd e nem precisaram mudar de hardware... mesmo com 200% de load conseguiam fazer ssh normal e tudo funcionava, nada travava Isso é vero mesmo. No provedor aqui que gerencio a TI e temos link hoje de 1Gbps para atender 4 Cidades, tinha Linux uns 2 anos atrás. Quando chegava em 200Mbps de tráfego aqui na cidade que eu fico e mais um load de 2.0 pra cima começavam os paus e travar o tráfego. Mantive o hardware e troquei para FreeBSD e meus problemas acabaram. :) a vm e a pilha tcp do freebsd sao imbativeis, com alto load de verdade( swap sei la em 60¨% ) o freebsd continua respondendo e o linux faz igual o pinguim, congela... kkk load alto no Linux fica impraticável qualquer acesso. sempre li e vi casos relatando isso... em alta carga o linux se perde todo, o windows 2008 se nao me engano copiou o esquema da pilha tcp do freebsd, por isso que funciona um pouco melhor que os antecessores.. na ultima copa da alemanha,TODA infra de rede da copa la, foi baseada em freebsd... pq sera ? olha o uptime dessa minha maquina: 9:07AM up 1268 days, 17:28, 1 user, load averages: 0.13, 0.13, 0.08 Lindo de se ver rsrsrsrs pena que devido à razões de segurança nunca vou chegar perto disso. ahhahaha e tem acesso pra cararmba, em media 18G por mes de trafego, tudo mysql O tráfego mensal lá nosso é de 5Tb rsrsrsr é muito envio e recebimento de dados dos torrents. :) AGORA ARRANCA LOGO ESSE LINUX E VOLTA PRO FREEBSD, EHEHE quem bom que foi constatado o problema, agora volta pro freebsd para poder dormir tranquilo, tirar ferias, ir pra balada, e esquecer que tem um server pra cuidar, ehe Com certeza mas agora vamos ter que esperar antes de mexer novamente. respirar um pouco. rsrsrsr Mas pode ter certeza que farei isso. seria interessante vc enviar um email finalizando o problema com todos detalhes que testou e as configuracoes finais que funcionaram. resgatar todas as partes da thread fica meio complicado, amanha aparece outro com o mesmo problema. abraco p.s e viu como o Brandi é o cara, eheh - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 10:01, Paulo Olivier Cavalcanti escreveu: Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. Sim fica no MySQL. Quando fiz a primeira conf do servidor em produção usei o my-huge.cnf e fui mexendo nos parâmetros e ajustando. Sendo que em algum momento removi ele. Quando fui jogar para o FreeBSD copiei o my-huge e adicionei as minhas outras confs e não reparei que o maldito estava lá como default e usando 8M. Sendo que no huge o default de conexões são 100 que é o padrão. Aí quando deixei esse cara lá e coloquei max_connections em 4000, estourou tudo. O problema foi só esse cara. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Bom dia, Esse parametro read_rnd_buffer_size fica em /etc/my.cnf Ele é capaz de fazer sim um verdadeiro estrago se não for bem configurado, pois ele aloca um valor muito alto de memória, a regra de ouro recomendada é que a cada 1MB de memória no servidor nós deixamos 1KB para o read_rnd_buffer_size Resumindo: Meu servidor MySQL tem 8GB de Ram logo um valor interessante seria: read_rnd_buffer_size = 4096KB O que já é mais do que suficiente para mim, pois minhas aplicações utilizando bastante ORDER BY para gerar relatórios, se esse não é o seu caso deixa logo 1024KB que já esta bom. Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Paulo Olivier Cavalcanti procavalca...@gmail.com escreveu: De: Paulo Olivier Cavalcanti procavalca...@gmail.com Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:01 Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. -- http://about.me/paulocavalcanti - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Olá Marcelo, Agora estou curioso, porque você utiliza esse valor enorme para max connections ? sua aplicação exige isso ? o desenvolvedor pode passar a usar pool de conexões, tarefa simples para fazer no PHP. Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Marcelo Gondim gon...@bsdinfo.com.br escreveu: De: Marcelo Gondim gon...@bsdinfo.com.br Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:33 Em 12/07/2012 10:01, Paulo Olivier Cavalcanti escreveu: Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. Sim fica no MySQL. Quando fiz a primeira conf do servidor em produção usei o my-huge.cnf e fui mexendo nos parâmetros e ajustando. Sendo que em algum momento removi ele. Quando fui jogar para o FreeBSD copiei o my-huge e adicionei as minhas outras confs e não reparei que o maldito estava lá como default e usando 8M. Sendo que no huge o default de conexões são 100 que é o padrão. Aí quando deixei esse cara lá e coloquei max_connections em 4000, estourou tudo. O problema foi só esse cara. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 10:34, NullCk escreveu: Bom dia, Esse parametro read_rnd_buffer_size fica em /etc/my.cnf Ele é capaz de fazer sim um verdadeiro estrago se não for bem configurado, pois ele aloca um valor muito alto de memória, a regra de ouro recomendada é que a cada 1MB de memória no servidor nós deixamos 1KB para o read_rnd_buffer_size Pois é e no meu caso piorava mais ainda porque o max_connections que eu precisava era de 4000. Nesse caso o consumo sobe mais ainda. :) Resumindo: Meu servidor MySQL tem 8GB de Ram logo um valor interessante seria: read_rnd_buffer_size = 4096KB Qual o seu max_connections ? Porque mesmo com esse valor aí se eu usasse 4000 ainda acho que ficaria muito alto. O que já é mais do que suficiente para mim, pois minhas aplicações utilizando bastante ORDER BY para gerar relatórios, se esse não é o seu caso deixa logo 1024KB que já esta bom. Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Paulo Olivier Cavalcanti procavalca...@gmail.com escreveu: De: Paulo Olivier Cavalcanti procavalca...@gmail.com Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:01 Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 10:38, NullCk escreveu: Olá Marcelo, Agora estou curioso, porque você utiliza esse valor enorme para max connections ? sua aplicação exige isso ? o desenvolvedor pode passar a usar pool de conexões, tarefa simples para fazer no PHP. Pior que exige porque é um site de torrents e são muitas conexões por causa do announce de cada cliente torrent de cada user nosso pelo mundão à fora. Mas com o memcache e umas alterações no sistema a gente conseguiu cair isso pra menos de 3000. :) Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Marcelo Gondim gon...@bsdinfo.com.br escreveu: De: Marcelo Gondim gon...@bsdinfo.com.br Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:33 Em 12/07/2012 10:01, Paulo Olivier Cavalcanti escreveu: Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. Sim fica no MySQL. Quando fiz a primeira conf do servidor em produção usei o my-huge.cnf e fui mexendo nos parâmetros e ajustando. Sendo que em algum momento removi ele. Quando fui jogar para o FreeBSD copiei o my-huge e adicionei as minhas outras confs e não reparei que o maldito estava lá como default e usando 8M. Sendo que no huge o default de conexões são 100 que é o padrão. Aí quando deixei esse cara lá e coloquei max_connections em 4000, estourou tudo. O problema foi só esse cara. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
2012/7/12 Marcelo Gondim gon...@bsdinfo.com.br: Em 12/07/2012 10:38, NullCk escreveu: Olá Marcelo, Agora estou curioso, porque você utiliza esse valor enorme para max connections ? sua aplicação exige isso ? o desenvolvedor pode passar a usar pool de conexões, tarefa simples para fazer no PHP. Pior que exige porque é um site de torrents e são muitas conexões por causa do announce de cada cliente torrent de cada user nosso pelo mundão à fora. Mas com o memcache e umas alterações no sistema a gente conseguiu cair isso pra menos de 3000. :) Acho que o NullCK tocou em um ponto importante... Você precisa desse número de conexões porque a tua aplicação está se conectando direto ao MySQL, sem nenhuma camada adicional. Isso significa que a cada hit/acesso resultará em acesso ao banco de dados (não contando com o memcache aqui). Utilizando um pool the conexoes você pode limitar o número de conexões simultanes ao teu servidor MySQL, além de reusar conexões. Digamos 1000, e assim que um cliente libera a conexão ela é entregue para outro na fila. Vale lembrar que quanto maior a concorrência, mais demorado é para atender todos ao mesmo tempo, por causa de compartilhamento de recursos, locks em threads, table locks etc etc etc... Então no final pode ser mais vantajoso como resultado utilizar um pool do que sobrecarregar teu MySQL com tantas conexoes simultaneas (deixando alguns clientes em hold por alguns instantes) Posso estar errado, mas enfim, meus 2 cents ;) -- William Grzybowski -- Agência Livre - www.agencialivre.com.br Curitiba/PR - Brasil - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 10:57, William Grzybowski escreveu: 2012/7/12 Marcelo Gondim gon...@bsdinfo.com.br: Em 12/07/2012 10:38, NullCk escreveu: Olá Marcelo, Agora estou curioso, porque você utiliza esse valor enorme para max connections ? sua aplicação exige isso ? o desenvolvedor pode passar a usar pool de conexões, tarefa simples para fazer no PHP. Pior que exige porque é um site de torrents e são muitas conexões por causa do announce de cada cliente torrent de cada user nosso pelo mundão à fora. Mas com o memcache e umas alterações no sistema a gente conseguiu cair isso pra menos de 3000. :) Acho que o NullCK tocou em um ponto importante... Você precisa desse número de conexões porque a tua aplicação está se conectando direto ao MySQL, sem nenhuma camada adicional. Isso significa que a cada hit/acesso resultará em acesso ao banco de dados (não contando com o memcache aqui). Utilizando um pool the conexoes você pode limitar o número de conexões simultanes ao teu servidor MySQL, além de reusar conexões. Digamos 1000, e assim que um cliente libera a conexão ela é entregue para outro na fila. Vou zoiar isso então. Pode ser um caminho para melhorar o consumo de recursos e não exigir um hardware melhor tão cedo. Hoje o acesso está excelente mas se for para melhorar com certeza será bem vindo. Vale lembrar que quanto maior a concorrência, mais demorado é para atender todos ao mesmo tempo, por causa de compartilhamento de recursos, locks em threads, table locks etc etc etc... Então no final pode ser mais vantajoso como resultado utilizar um pool do que sobrecarregar teu MySQL com tantas conexoes simultaneas (deixando alguns clientes em hold por alguns instantes) Posso estar errado, mas enfim, meus 2 cents ;) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Bom dia pessoal... sou praticamente leigo neste assunto, mas to acompanhando atentamente a discussao, e nestes dias tambem estava mexendo com o um servidor mysql em um freebsd9, esta opcao read_rnd_buffer_size=8 é default no arquivo my-huge.cnf, no medium é 512 e no small 256 eu uso o mysqltunner e usando o arquivo de configuracao my-huge o comportamento é o mesmo do setup do Gondim, setando em 5 mil conexoes, ele pedia mais de 64 giga de ram... Em 12.07.2012 01:40, Marcelo Gondim escreveu: Em 12/07/2012 00:24, Edson Brandi escreveu: Marcelo, O problema está nessa configuração ai do mysql que vc esta usando... Refiz um teste aqui com o FreeBSD 64 bits... Se eu uso o /usr/local/share/mysql/my-huge.cnf como sendo o meu /var/db/mysql/my.cnf e seto o max_connections=4000 , o output do tunning primer é o que vc está obtendo: MEMORY USAGE Max Memory Ever Allocated : 572 M Configured Max Per-thread Buffers : 48.21 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 48.76 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Se eu uso o mysqld com a configuração default (default = não existe o my.cnf), e adiciono apenas o parâmetro para 4.000 conexões (o arquivo vai ficar com apenas 2 linhas): [mysqld] max_connections=4000 O output do tuning-primer.sh é o que eu tinha enviado antes (muito semelhante no linux e no FreeBSD): MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 3.74G Max memory limit exceeds 90% of physical memory Se eu uso o mesmo arquivo de configuração (/usr/local/share/mysql/my-huge.cnf ) no servidor Linux, fazendo os ajustes necessários para que o mysqld rode, visto que aqui no meu lab o daemon no linux nem sobe com este arquivo de configuração copiado do FreeBSD se vc não adicionar as linhas abaixo na sessão [mysqld]: datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql O resultado é o mesmo que no FreeBSD: MEMORY USAGE Max Memory Ever Allocated : 584 M Configured Max Per-thread Buffers : 48.46 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 49.00 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Ou seja, acho pouco provável que o seu servidor Linux e o seu servidor FreeBSD estejam rodando exatamente com a mesma configuração no MySQL (este my-huge.cnf)... Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 11:15, Marcelo da Silva escreveu: Bom dia pessoal... sou praticamente leigo neste assunto, mas to acompanhando atentamente a discussao, e nestes dias tambem estava mexendo com o um servidor mysql em um freebsd9, esta opcao read_rnd_buffer_size=8 é default no arquivo my-huge.cnf, no medium é 512 e no small 256 eu uso o mysqltunner e usando o arquivo de configuracao my-huge o comportamento é o mesmo do setup do Gondim, setando em 5 mil conexoes, ele pedia mais de 64 giga de ram... Marcelo comenta o read_rnd_buffer_size que vai resolver seu problema. Aí você vai tunando as outras variáveis. :) Ele tem esse valor por default porque o max_connections default são 100 mas daí usar 1000, 2000... aí a coisa muda de figura. ;) Em 12.07.2012 01:40, Marcelo Gondim escreveu: Em 12/07/2012 00:24, Edson Brandi escreveu: Marcelo, O problema está nessa configuração ai do mysql que vc esta usando... Refiz um teste aqui com o FreeBSD 64 bits... Se eu uso o /usr/local/share/mysql/my-huge.cnf como sendo o meu /var/db/mysql/my.cnf e seto o max_connections=4000 , o output do tunning primer é o que vc está obtendo: MEMORY USAGE Max Memory Ever Allocated : 572 M Configured Max Per-thread Buffers : 48.21 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 48.76 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Se eu uso o mysqld com a configuração default (default = não existe o my.cnf), e adiciono apenas o parâmetro para 4.000 conexões (o arquivo vai ficar com apenas 2 linhas): [mysqld] max_connections=4000 O output do tuning-primer.sh é o que eu tinha enviado antes (muito semelhante no linux e no FreeBSD): MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 3.74G Max memory limit exceeds 90% of physical memory Se eu uso o mesmo arquivo de configuração (/usr/local/share/mysql/my-huge.cnf ) no servidor Linux, fazendo os ajustes necessários para que o mysqld rode, visto que aqui no meu lab o daemon no linux nem sobe com este arquivo de configuração copiado do FreeBSD se vc não adicionar as linhas abaixo na sessão [mysqld]: datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql O resultado é o mesmo que no FreeBSD: MEMORY USAGE Max Memory Ever Allocated : 584 M Configured Max Per-thread Buffers : 48.46 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 49.00 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Ou seja, acho pouco provável que o seu servidor Linux e o seu servidor FreeBSD estejam rodando exatamente com a mesma configuração no MySQL (este my-huge.cnf)... Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
max_connections no meu caso ta em 300 e ainda é muito. Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Marcelo Gondim gon...@bsdinfo.com.br escreveu: De: Marcelo Gondim gon...@bsdinfo.com.br Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:46 Em 12/07/2012 10:34, NullCk escreveu: Bom dia, Esse parametro read_rnd_buffer_size fica em /etc/my.cnf Ele é capaz de fazer sim um verdadeiro estrago se não for bem configurado, pois ele aloca um valor muito alto de memória, a regra de ouro recomendada é que a cada 1MB de memória no servidor nós deixamos 1KB para o read_rnd_buffer_size Pois é e no meu caso piorava mais ainda porque o max_connections que eu precisava era de 4000. Nesse caso o consumo sobe mais ainda. :) Resumindo: Meu servidor MySQL tem 8GB de Ram logo um valor interessante seria: read_rnd_buffer_size = 4096KB Qual o seu max_connections ? Porque mesmo com esse valor aí se eu usasse 4000 ainda acho que ficaria muito alto. O que já é mais do que suficiente para mim, pois minhas aplicações utilizando bastante ORDER BY para gerar relatórios, se esse não é o seu caso deixa logo 1024KB que já esta bom. Thiago Dias aka nullck Powered By Linux LPIC 1| Novell CLA | ITILv3 Linux For Servers Macintosh For Graphics Windows For Play Solitaire --- Em qui, 12/7/12, Paulo Olivier Cavalcanti procavalca...@gmail.com escreveu: De: Paulo Olivier Cavalcanti procavalca...@gmail.com Assunto: Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO] Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 12 de Julho de 2012, 10:01 Em Thu, 12 Jul 2012 01:40:30 -0300, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs Desculpe a minha ignorância, mas não entendi. Esse read_rnd_buffer_size fica dentro das confs do mysql ou do freebsd? Você agora consegue setar as conexões para 4000 sem matar o servidor? Estou acompanhando essa thread com grande interesse e ansioso para uma solução. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Me deu vontade de fazer uma coisa agora. Pelo que vi no codigo do anounce.php a estrutura e bem simples e as transacoes do update tambem. Tenho um servidor em java com NIO qie nao usa threads para atender cada request, igual o select em C. Da pra montar essa estrutura na ram e atualizar direto na mesma, deixando as atualizacoes para o db numa fifo monitorada dai sim numa thread. Iria ficar o cao xupando manga de tao rapido alem do que poderia atender muuito mais anunces por segundo na mesma maquina, nao teria esse overhead todo do apache e blablabla. O dia que tiver tempo e for pra aliviar os ares vou fazer uns testes. E sim o java roda muito bem no freebsd. Abs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 13:16, Leonardo Augusto escreveu: Me deu vontade de fazer uma coisa agora. Pelo que vi no codigo do anounce.php a estrutura e bem simples e as transacoes do update tambem. Tenho um servidor em java com NIO qie nao usa threads para atender cada request, igual o select em C. Da pra montar essa estrutura na ram e atualizar direto na mesma, deixando as atualizacoes para o db numa fifo monitorada dai sim numa thread. Iria ficar o cao xupando manga de tao rapido alem do que poderia atender muuito mais anunces por segundo na mesma maquina, nao teria esse overhead todo do apache e blablabla. O dia que tiver tempo e for pra aliviar os ares vou fazer uns testes. E sim o java roda muito bem no freebsd. Opa Leonardo existe um tracker, que na verdade o announce é conhecido como tracker, só que feito em C. Só não implementamos ele ainda para testar. É esse cara aqui: http://www.visigod.com/xbt-tracker/installation Grande sites de torrent e maiores que o nosso usam esse tracker. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Em 12 de julho de 2012 16:10, Nilton Jose Rizzo ri...@i805.com.br escreveu: Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12/07/2012 16:10, Nilton Jose Rizzo escreveu: Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes Opa Rizzo já resolvemos o problema. Era uma variável do próprio mysql que tava me ferrando todo. ;) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Em 12 de julho de 2012 16:10, Nilton Jose Rizzo ri...@i805.com.br escreveu: Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12 de julho de 2012 16:58, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Em 12 de julho de 2012 16:10, Nilton Jose Rizzo ri...@i805.com.br escreveu: Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd E ai, Gondim, resolveu tudo? Agora o MS já tá no FreeBSD ou teve que voltar pro Linux? O problema era só essa variável? -- Att, Marcus Vinicius. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12 de julho de 2012 16:58, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Você resolveu o problema de alocar memória... mas e a performance do mysql? Não ficou afetada por conta da redução drástica do read_rnd_buffer_size? ;-) Abs. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12/07/2012 17:06, Marcus Vinicius. escreveu: Em 12 de julho de 2012 16:58, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Em 12 de julho de 2012 16:10, Nilton Jose Rizzo ri...@i805.com.br escreveu: Em Wed, 11 Jul 2012 15:16:57 -0300, Marcelo Gondim escreveu Em 11/07/2012 14:52, Edson Brandi escreveu: Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Será que sem querer descobri algo interessante? rsrsrsrsrs Marcelo, Estava dando uma olhada em como o mysql tuning primer (https://launchpad.net/mysql-tuning-primer/), chega nos números. Pelo que vi ele não está usando nenhuma variavel do sistema operacional, e esta fazendo praticamente todas as contas tendo como input variaveis do mysql. Com base nesta lógica de calculo a unica explicação que vejo pros numeros estarem diferentes é se estas variaveis forem diferentes entre o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me parece ser algo relacionado ao sistema operacional. Pois é mas se pegar as confs copiar de um pra outro usando as mesmas variáveis e só mudando o max_connection já dá uma grande diferença. Também quero encontrar uma solução para isso. Também pensei no seguinte: e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os valores estivesses errados e fossem proximos dos do Linux. Então tudo deveria funcionar normalmente mas não funciona. Quando estouro com o max_connection passa à dar esse erro aqui: 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 Se procurar no google por esse erro vamos ver que muita gente tenta resolver isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento usar os 4000 começa à dar os erros de acesso que postei acima. Aí mais à frente descobri essa página: http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html Onde no final está escrito assim: 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. Lendo esse parágrafo me faz pensar da seguinte maneira: Otimização no código para ambiente Linux Uma vez que eles fornecem os binários já compilados prontos para instalar. Isso me faz recordar uma discução antiga sobre a venda da sum para a Oracle . como você usa apenas MYISAM, tente uma versão anterior a 5.x, a última versão 4 .x ... execute em ambos os sistemas e verifique se há essa diferença gritante... sei lá é apenas uma teoria da conspiração flames /dev/null PS.: Já tentopu rodar o mesmo binário na emulação Linux no free, como já disseram antes -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd E ai, Gondim, resolveu tudo? Agora o MS já tá no FreeBSD ou teve que voltar pro Linux? O problema era só essa variável? Opa Marcus parece que era só isso mas não tive como esperar. Próxima oportunidade eu migro pro FreeBSD. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12/07/2012 17:35, Eduardo Schoedler escreveu: Em 12 de julho de 2012 16:58, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Você resolveu o problema de alocar memória... mas e a performance do mysql? Não ficou afetada por conta da redução drástica do read_rnd_buffer_size? ;-) Abs. Não ficou não tá rodando sem ele normalmente. :D - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 12/07/12 17:35, Eduardo Schoedler escreveu: Em 12 de julho de 2012 16:58, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 12/07/2012 16:18, Otavio Augusto escreveu: Tenho um sistema que eu mesmo desnvolvi e rodando em FreeBSD 9 com Mysql 5.5 e PHP53 . já cheguei a uns 2600 acessos simultaneos sem nehum tunning e rodando perfeito Agora vai ficar perfeito :) era a maldita da variável read_rnd_buffer_size que no my-huge.cnf vem com 8M sendo que se mantiver os 8M ali e aumentar o max_connections pra 1000, 2000... 4000 aí a coisa fica feia. Só removi ele deixando o valor default que resolveu. Você resolveu o problema de alocar memória... mas e a performance do mysql? Não ficou afetada por conta da redução drástica do read_rnd_buffer_size? ;-) Abs. Poderia fazer um post contendo um resumo do que foi feito, de forma que fique documentado para a lista? Acho que seria até interessante este estudo de caso ir para a página da FUG, se você topar. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Achei interessante essa thread, por dois motivos. 1) Tivemos a oportunidade de ver e ajudar a solucionar um problema que teoricamente é simples ( configuração ) , porém quando vivenciamos na prática verifica-se de dificil solução, e com a ajuda de grandes nomes da comunidade tivemos uma solução satisfatória. 2) Como criar o caos em uma thread grande como essa, porque digo isso? aposto que muitos de vocês utilizam programas leitores de email que conseguem seguir as threads, para mim ficou dificil, pois utilizaram os emails originais e apenas substituiram o título e mandaram ver. Como isso atrapalha ... pois os programas utilizam o id da mensagem para criar um indice para a thread, então tive que ler outros emails para ter certeza que não faziam parte da thread original, porém tive que entrar em cada um, pois quando pedi para separar a thread veio junto muitos outros emails. Não sei se me fiz entender, mas peço encarecidamente aos que utilizam essa técnica para evita-la pois a thred torna-se um caos! Obrigado, -- Nilton José Rizzo 805 Informatica Disseminando tecnologias 021 2413 9786 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
vale lembrar que essa variavel so afeta o myisam(pelo que entendi), por isso que desde o comeco eu disse que usar o innodb era melhor, eheh - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 11:25, Thiago Rodrigues escreveu: Caro, Marcelo, Primeiramente tu tem que verificar se ambas as variaveis do mysql são indeticas, pois o mysql separa variaveis globais, e variaveis por conexões, se as variaveis por conexões do mysql do freebsd tiverem um valor alto elas serão multiplicadas, pelo numero maximo de conexões. Sim estão certas. Tente você colocar 4000 conexões no seu MySQL do FreeBSD. Pode mexer no que for vai estourar. :( Outro fator, o kernel do seu freebsd esta para 64 bits correto? Sim lógico. :) senão não conseguiria nem ver os 12Gb de ram FreeBSD xxx.xxx.br 9.0-STABLE FreeBSD 9.0-STABLE #25: Mon Jul 9 12:22:33 BRT 2012 r...@xxx.xxx.br:/usr/obj/usr/src/sys/GONDIM amd64 Verifique isso por favor. Atenciosamente, Thiago Cesar Em 11 de julho de 2012 10:36, Marcelo Gondim gon...@bsdinfo.com.br mailto:gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- * A entrada de seus negócios para o mundo virtual Thiago Cesar Diretor TI MSN:thiago_rodrig...@hotmail.com mailto:thiago_rodrig...@hotmail.com Skype: thiago_ceor --- http://www.kionux.com.br Kionux Soluções em Internet LTDA. Av. Garibalde, 1114 - Sala 15 - Vila A CEP 85861-550 - Foz do Iguaçu - PR Telefone: +55 (45) 3572-5000 * - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 10:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) Marcelo, Antes de palpitar, me diga uma coisa... O seu FreeBSD roda em 32 ou 64 Bits? O seu mysqld é 32 ou 64 bits? Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... Cada thread do mysql vai consumir no minimo uns 200k de memoria, para 4000 conexões/threads vc precisa permitir no minimo 1.5 Gb de memoria alocada por processo. De uma olhada nos demais limites do seu sistema com o ulimit-a , vc pode precisar mexer em outros items... Como estão os parâmetros da sessão [mysqld] do seu my.cnf na sua instalação FreeBSD e na sua instalação Linux? Eles estão iguais? Existem uma série de itens de configuração que mudam radicalmente o consumo de memoria do seu servidor, e a comparação pra ser justa tem que ser feita em cenários iguais. Se tiver tempo, recomendo a leitura do artigo http://mysql.rjweb.org/doc.php/memory , vai ajudar a entender melhor como o mysql trata o uso de memoria. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
hehe isso do mysql ta virando pessoal ja. vamos dar um jeito nisso. eu so nao posso fazer mais testes em funcao da minha condicao de deitado temporariamenre. passa as configs do kernel e o my.cnf que usou, o sysctl -a grep kern tb e interessante. acho que tem muita gente aqui que tem interesse no caso e com condicoes de ajudar. sera que nao tem a ver com o tipo do scheduke usado? ja testou com is dois tipos? faz o teste de rodar o binario do linux no bsd. e so baixar o tgz e rodar via um comando la de emulacao de linux que nao lembro agora. quando eu ficar bom, vou pegar um dell quad com raid e 8g que ta parado e vou instalar esse 8 ou 9 pra testar ate la so posdo dar palpite, hehe Em 11/07/2012 10:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 11:49, Edson Brandi escreveu: Em 11 de julho de 2012 10:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) Marcelo, Antes de palpitar, me diga uma coisa... O seu FreeBSD roda em 32 ou 64 Bits? O seu mysqld é 32 ou 64 bits? Opa Edson blz? 64 bits. Tudo compilado, nada instalado por pacote. Toda instalação feita via ports em amd64. :) Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... # sysctl kern.maxdsiz kern.maxdsiz: 34359738368 Cada thread do mysql vai consumir no minimo uns 200k de memoria, para 4000 conexões/threads vc precisa permitir no minimo 1.5 Gb de memoria alocada por processo. De uma olhada nos demais limites do seu sistema com o ulimit-a , vc pode precisar mexer em outros items... # ulimit -a socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 33554432 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 20 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 524288 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited swap size (kbytes, -w) unlimited Pois é Edson estou tentando descobrir mas tá complicado. :) Como estão os parâmetros da sessão [mysqld] do seu my.cnf na sua instalação FreeBSD e na sua instalação Linux? Eles estão iguais? Existem uma série de itens de configuração que mudam radicalmente o consumo de memoria do seu servidor, e a comparação pra ser justa tem que ser feita em cenários iguais. Estão iguais sim. Fiz só para efeito de testes. O que acontece é que não importa o quanto eu acerte os outros parâmetros no my.cnf, colocar 4000 em max_connections vai tudo pro ralo. Se você tentar fazer aí acredito que vá ocorrer o mesmo resultado. Isso surgiu por causa do nosso site de torrents que devido ao announce e quantidade de peers o número de conexões chegam em 4000. Se tiver tempo, recomendo a leitura do artigo http://mysql.rjweb.org/doc.php/memory , vai ajudar a entender melhor como o mysql trata o uso de memoria. Vou ler sim. Mas realmente está muito estranho isso. Como está gritante essa diferença. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 12:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 11:49, Edson Brandi escreveu: Em 11 de julho de 2012 10:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) Marcelo, Antes de palpitar, me diga uma coisa... O seu FreeBSD roda em 32 ou 64 Bits? O seu mysqld é 32 ou 64 bits? Opa Edson blz? 64 bits. Tudo compilado, nada instalado por pacote. Toda instalação feita via ports em amd64. :) Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... # sysctl kern.maxdsiz kern.maxdsiz: 34359738368 Cada thread do mysql vai consumir no minimo uns 200k de memoria, para 4000 conexões/threads vc precisa permitir no minimo 1.5 Gb de memoria alocada por processo. De uma olhada nos demais limites do seu sistema com o ulimit-a , vc pode precisar mexer em outros items... # ulimit -a socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 33554432 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 20 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 524288 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited swap size (kbytes, -w) unlimited Pois é Edson estou tentando descobrir mas tá complicado. :) Como estão os parâmetros da sessão [mysqld] do seu my.cnf na sua instalação FreeBSD e na sua instalação Linux? Eles estão iguais? Existem uma série de itens de configuração que mudam radicalmente o consumo de memoria do seu servidor, e a comparação pra ser justa tem que ser feita em cenários iguais. Estão iguais sim. Fiz só para efeito de testes. O que acontece é que não importa o quanto eu acerte os outros parâmetros no my.cnf, colocar 4000 em max_connections vai tudo pro ralo. Se você tentar fazer aí acredito que vá ocorrer o mesmo resultado. Isso surgiu por causa do nosso site de torrents que devido ao announce e quantidade de peers o número de conexões chegam em 4000. Se tiver tempo, recomendo a leitura do artigo http://mysql.rjweb.org/doc.php/memory , vai ajudar a entender melhor como o mysql trata o uso de memoria. Vou ler sim. Mas realmente está muito estranho isso. Como está gritante essa diferença. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Qual a versão do teu FreeBSD ? -- Ricardo Carlini Sperandio Analista/Consultor Linux Sênior LPIC-3 Connectcom - GISUT / CEF GEDEL: Grupo Especializado em Desenvolvimento Linux VIPLAB/PUC-MG mestrando em informática DCC/UFMG - Bacharel em Ciência da Computação Computers are like air conditioners. They don't work when you open Windows. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 12:14, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... # sysctl kern.maxdsiz kern.maxdsiz: 34359738368 Estranho... Pelo sintoma é como se o mysql não estivesse conseguindo alocar a memoria mesmo com o seu kernel permitindo isso :\ Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz kern.dflssiz kern.maxdsiz kern.dfldsiz kern.maxtsiz Vc mencionou que chegou a rodar com até 1.000 no numero de conexões, como ficou o report dos parâmetros de MEMORY USAGE neste cenário? []´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 11:50, Leonardo Augusto escreveu: hehe isso do mysql ta virando pessoal ja. vamos dar um jeito nisso. não é? rsrsrsr eu so nao posso fazer mais testes em funcao da minha condicao de deitado temporariamenre. passa as configs do kernel e o my.cnf que usou, o sysctl -a grep kern tb e interessante. Pra testar eu peguei my-huge mesmo e só adicionei o max_connections sem acessos à base. Só pra efeito de teste mesmo. Agora o do Linux que tá em produção é esse aqui: [mysqld] open-files-limit = 20 user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language= /usr/share/mysql/english skip-external-locking bind-address= 127.0.0.1 low_priority_updates= 1 concurrent_insert = 2 key_buffer_size = 2G max_allowed_packet = 512M thread_stack= 512K thread_cache_size = 128 myisam-recover = BACKUP max_connections= 4000 table_cache= 5000 thread_concurrency = 24 query_cache_limit = 16M query_cache_size= 128M expire_logs_days= 10 max_binlog_size = 100M acho que tem muita gente aqui que tem interesse no caso e com condicoes de ajudar. sera que nao tem a ver com o tipo do scheduke usado? ja testou com is dois tipos? Estou usando o ULE mas você acha que ficaria melhor o 4BSD? # SCHED_4BSD is the historical, proven, BSD scheduler. It has a global run # queue and no CPU affinity which makes it suboptimal for SMP. It has very # good interactivity and priority selection. # SCHED_ULE provides significant performance advantages over 4BSD on many # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues # and scheduler locks. It also has a stronger notion of interactivity # which leads to better responsiveness even on uniprocessor machines. This # is the default scheduler. Teoricamente o ULE seria melhor ao meu ver. faz o teste de rodar o binario do linux no bsd. e so baixar o tgz e rodar via um comando la de emulacao de linux que nao lembro agora. quando eu ficar bom, vou pegar um dell quad com raid e 8g que ta parado e vou instalar esse 8 ou 9 pra testar Show vamos desbagaçar esse pepino hahahahaha ate la so posdo dar palpite, hehe Em 11/07/2012 10:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Cara o memcache já foi um puta palpite que hoje em dia tá muto bom lá no site. O site que tem a quantidade de acessos, mais de 400mil peers, quase 100mil users, pra mais de 70.000 torrents e as páginas de consulta estão sendo geradas em 0,00... segundos. Valeu pela dica e consegui convencer o programador à implementar. rsrsrs Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 12:23, Ricardo Carlini Sperandio escreveu: Em 11 de julho de 2012 12:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 11:49, Edson Brandi escreveu: Em 11 de julho de 2012 10:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) Marcelo, Antes de palpitar, me diga uma coisa... O seu FreeBSD roda em 32 ou 64 Bits? O seu mysqld é 32 ou 64 bits? Opa Edson blz? 64 bits. Tudo compilado, nada instalado por pacote. Toda instalação feita via ports em amd64. :) Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... # sysctl kern.maxdsiz kern.maxdsiz: 34359738368 Cada thread do mysql vai consumir no minimo uns 200k de memoria, para 4000 conexões/threads vc precisa permitir no minimo 1.5 Gb de memoria alocada por processo. De uma olhada nos demais limites do seu sistema com o ulimit-a , vc pode precisar mexer em outros items... # ulimit -a socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 33554432 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 20 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 524288 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited swap size (kbytes, -w) unlimited Pois é Edson estou tentando descobrir mas tá complicado. :) Como estão os parâmetros da sessão [mysqld] do seu my.cnf na sua instalação FreeBSD e na sua instalação Linux? Eles estão iguais? Existem uma série de itens de configuração que mudam radicalmente o consumo de memoria do seu servidor, e a comparação pra ser justa tem que ser feita em cenários iguais. Estão iguais sim. Fiz só para efeito de testes. O que acontece é que não importa o quanto eu acerte os outros parâmetros no my.cnf, colocar 4000 em max_connections vai tudo pro ralo. Se você tentar fazer aí acredito que vá ocorrer o mesmo resultado. Isso surgiu por causa do nosso site de torrents que devido ao announce e quantidade de peers o número de conexões chegam em 4000. Se tiver tempo, recomendo a leitura do artigo http://mysql.rjweb.org/doc.php/memory , vai ajudar a entender melhor como o mysql trata o uso de memoria. Vou ler sim. Mas realmente está muito estranho isso. Como está gritante essa diferença. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Qual a versão do teu FreeBSD ? Oi Ricardo, testei com o 9-Stable e com o 8.3-Stable ambos amd64. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 12:36, Edson Brandi escreveu: Em 11 de julho de 2012 12:14, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Como está o seu kern.maxdsiz ? Pelos numero me parece que sua maquina ainda está usando o tamanho default de 512 Mb como sendo o segmento máximo de memoria que pode ser alocada por um processo, esse é o primeiro problema que eu vejo... # sysctl kern.maxdsiz kern.maxdsiz: 34359738368 Estranho... Pelo sintoma é como se o mysql não estivesse conseguindo alocar a memoria mesmo com o seu kernel permitindo isso :\ pois é. sinistro! Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz kern.dflssiz kern.maxdsiz kern.dfldsiz kern.maxtsiz kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Vc mencionou que chegou a rodar com até 1.000 no numero de conexões, como ficou o report dos parâmetros de MEMORY USAGE neste cenário? Consegui mas praticamente estourando o uso. Olha só com 1000 em max_connections: MEMORY USAGE Max Memory Ever Allocated : 649 M Configured Max Per-thread Buffers : 12.11 G Configured Max Global Buffers : 426 M Configured Max Memory Limit : 12.53 G Physical Memory : 13.00 G Max memory limit exceeds 90% of physical memory Só se eu concluir que o FreeBSD precisa de muito mais memória que o Linux para rodar com o mesmo max_connections no MySQL. Se for isso por que seria tão diferente? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 13:55, Marcelo Gondim escreveu: Em 11/07/2012 11:50, Leonardo Augusto escreveu: hehe isso do mysql ta virando pessoal ja. vamos dar um jeito nisso. não é? rsrsrsr eu so nao posso fazer mais testes em funcao da minha condicao de deitado temporariamenre. passa as configs do kernel e o my.cnf que usou, o sysctl -a grep kern tb e interessante. Pra testar eu peguei my-huge mesmo e só adicionei o max_connections sem acessos à base. Só pra efeito de teste mesmo. Agora o do Linux que tá em produção é esse aqui: [mysqld] open-files-limit = 20 user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language= /usr/share/mysql/english skip-external-locking bind-address= 127.0.0.1 low_priority_updates= 1 concurrent_insert = 2 key_buffer_size = 2G max_allowed_packet = 512M thread_stack= 512K thread_cache_size = 128 myisam-recover = BACKUP max_connections= 4000 table_cache= 5000 thread_concurrency = 24 query_cache_limit = 16M query_cache_size= 128M expire_logs_days= 10 max_binlog_size = 100M Esqueci de colocar o resultado dele: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Fico impressionado é que com 4000 ele usa bem menos memória que no FreeBSD. 11.71G e 13.85G acho que tem muita gente aqui que tem interesse no caso e com condicoes de ajudar. sera que nao tem a ver com o tipo do scheduke usado? ja testou com is dois tipos? Estou usando o ULE mas você acha que ficaria melhor o 4BSD? # SCHED_4BSD is the historical, proven, BSD scheduler. It has a global run # queue and no CPU affinity which makes it suboptimal for SMP. It has very # good interactivity and priority selection. # SCHED_ULE provides significant performance advantages over 4BSD on many # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues # and scheduler locks. It also has a stronger notion of interactivity # which leads to better responsiveness even on uniprocessor machines. This # is the default scheduler. Teoricamente o ULE seria melhor ao meu ver. faz o teste de rodar o binario do linux no bsd. e so baixar o tgz e rodar via um comando la de emulacao de linux que nao lembro agora. quando eu ficar bom, vou pegar um dell quad com raid e 8g que ta parado e vou instalar esse 8 ou 9 pra testar Show vamos desbagaçar esse pepino hahahahaha ate la so posdo dar palpite, hehe Em 11/07/2012 10:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Cara o memcache já foi um puta palpite que hoje em dia tá muto bom lá no site. O site que tem a quantidade de acessos, mais de 400mil peers, quase 100mil users, pra mais de 70.000 torrents e as páginas de consulta estão sendo geradas em 0,00... segundos. Valeu pela dica e consegui convencer o programador à implementar. rsrsrs Pessoal, Peguei uma base mysql rodando no FreeBSD e setei o max_connection para 4000. Tenho 12Gb de ram nessa máquina que fiz o teste, meu i7. :) após rodar o tuning-primer o memory usage simplesmente estoura. Conforme abaixo: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Valores até 1000 eu consegui no FreeBSD, sem estourar, mas ocupava bastante ram mesmo assim. Quando eu faço a mesma coisa em uma máquina equivalente, com mais memória, só que com Linux, usando os 4000 em max_connections a coisa fica boa conforme abaixo: MEMORY USAGE Max Memory Ever Allocated : 10.10 G Configured Max Per-thread Buffers : 11.71 G Configured Max Global Buffers : 2.13 G Configured Max Memory Limit : 13.85 G Physical Memory : 23.53 G Max memory limit seem to be within acceptable norms Reparem que no caso do Linux o Configured Max Per-thread Buffers e o Configured Max Memory Limit não estouraram a ram disponível. O que poderia estar causando isso no FreeBSD? Já procurei em tudo quanto foi lugar pra tentar resolver e a única coisa que eu havia visto é que no Linux suportaria as 4000 conexões mas em outras plataformas não. Quem puder fazer esses testes e comprovar é só dizer. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 14:21, Edson Brandi ebra...@fugspbr.org escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Tem um outro parâmetro que mudaram no 7.2 em diante, passou a aceitar 2GB+: kern.ipc.shmmax=2147483648 Chegou a testar? -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 14:21, Edson Brandi ebra...@fugspbr.org escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Edson Marcelo, Pergunta obvia que esqueci de fazer... o seu kern.ipc.somaxconn está setado para mais de 4.000 , certo? Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 14:21, Edson Brandi escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Coloquei eles no loader.conf, bootei e joguei os 4000 lá e aqui está o resultado: 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 : 13.00 G Max memory limit exceeds 90% of physical memory Muito sinistro e tipo isso foi feito em mais de uma máquina e os valores são sempre altos. :( Creio que se eu jogasse uns 64Gb de ram na máquina funcionaria mas puts muita diferença. Será que sem querer descobri algo interessante? rsrsrsrsrs Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 14:32, Eduardo Schoedler escreveu: Em 11 de julho de 2012 14:21, Edson Brandi ebra...@fugspbr.org escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Tem um outro parâmetro que mudaram no 7.2 em diante, passou a aceitar 2GB+: kern.ipc.shmmax=2147483648 Chegou a testar? O meu já estava em 2G, joguei pra 4G e 6G e não surtiu efeito. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 14:33, Edson Brandi escreveu: Em 11 de julho de 2012 14:21, Edson Brandi ebra...@fugspbr.org escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Edson Marcelo, Pergunta obvia que esqueci de fazer... o seu kern.ipc.somaxconn está setado para mais de 4.000 , certo? Sim. kern.ipc.somaxconn: 4096 sendo que testei até com valores mais altos também. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 14:39, Marcelo Gondim escreveu: Em 11/07/2012 14:33, Edson Brandi escreveu: Em 11 de julho de 2012 14:21, Edson Brandi ebra...@fugspbr.org escreveu: Em 11 de julho de 2012 14:06, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Vc mencionou que a sua maquina tem 12 Gb de memoria, certo? Como estão os parâmetros abaixo no seu Freebsd? kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 Marcelo, Faz uma juste ai no seu loader.conf, para: kern.dflssiz=512M kern.maxdsiz=10G kern.dfldsiz=4G kern.maxssiz=10G kern.maxtsiz=4G Da um boot na maquina, seta o max_connection para 4.000, e roda o report de novo. Manda o resultado aqui pra gente :) Edson Marcelo, Pergunta obvia que esqueci de fazer... o seu kern.ipc.somaxconn está setado para mais de 4.000 , certo? Sim. kern.ipc.somaxconn: 4096 sendo que testei até com valores mais altos também. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Edson o meu sysctl.conf é esse aqui: kern.ipc.somaxconn=4096 kern.ipc.shmmax=2147483648 kern.ipc.maxsockets=204800 kern.ipc.nmbclusters=262144 kern.ps_arg_cache_limit=4096 kern.maxfiles=204800 kern.maxfilesperproc=20 kern.maxvnodes=20 kern.timecounter.hardware=HPET net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.log_redirect=0 net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet6.icmp6.nodeinfo=0 net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 net.inet6.icmp6.rediraccept=0 net.inet.ip.ttl=128 net.inet.tcp.msl=5000 net.inet.tcp.maxtcptw=20 net.inet.tcp.fast_finwait2_recycle=1 net.inet.ip.intr_queue_maxlen=4096 net.inet.ip.dummynet.io_fast=1 vfs.ufs.dirhash_maxmem=67108864 vfs.read_max=64 net.inet.tcp.ecn.enable=1 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_max=65536 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=2 net.inet.ip.fw.dyn_short_lifetime=10 net.link.ether.ipfw=1 machdep.panic_on_nmi=0 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu:
Será que sem querer descobri algo interessante? rsrsrsrsrs
Marcelo,
Estava dando uma olhada em como o mysql tuning primer
(https://launchpad.net/mysql-tuning-primer/), chega nos números.
Pelo que vi ele não está usando nenhuma variavel do sistema
operacional, e esta fazendo praticamente todas as contas tendo como
input variaveis do mysql.
Com base nesta lógica de calculo a unica explicação que vejo pros
numeros estarem diferentes é se estas variaveis forem diferentes entre
o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me
parece ser algo relacionado ao sistema operacional.
A unica informação que ele usa do sistema operacional é a quantidade de memoria:
get_system_info () {
export OS=$(uname)
# Get information for various UNIXes
if [ $OS = 'Darwin' ]; then
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(sysctl -n hw.memsize)
export duflags=''
elif [ $OS = 'FreeBSD' ] || [ $OS = 'OpenBSD' ]; then
## On FreeBSD must be root to locate sockets.
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(sysctl -n hw.realmem)
export duflags=''
elif [ $OS = 'Linux' ] ; then
## Includes SWAP
## export physical_memory=$(free -b | grep -v buffers | awk
'{ s += $2 } END { printf(%.0f\n, s ) }')
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(awk '/^MemTotal/ { printf(%.0f,
$2*1024 ) }' /proc/meminfo)
export duflags='-b'
elif [ $OS = 'SunOS' ] ; then
ps_socket=$(netstat -an | awk '/mysql(.*)?.sock/ { print $5 }'
| head -1)
found_socks=$(netstat -an | awk '/mysql(.*)?.sock/ { print $5 }')
export physical_memory=$(prtconf | awk '/^Memory\ size:/ {
print $3*1048576 }')
fi
if [ -z $(which bc) ] ; then
echo Error: Command line calculator 'bc' not found!
exit
fi
}
Colei a função que calcula a alocação de memoria abaixo:
total_memory_used () {
## -- Total Memory Usage -- ##
cecho MEMORY USAGE boldblue
mysql_variable \'read_buffer_size\' read_buffer_size
mysql_variable \'read_rnd_buffer_size\' read_rnd_buffer_size
mysql_variable \'sort_buffer_size\' sort_buffer_size
mysql_variable \'thread_stack\' thread_stack
mysql_variable \'max_connections\' max_connections
mysql_variable \'join_buffer_size\' join_buffer_size
mysql_variable \'tmp_table_size\' tmp_table_size
mysql_variable \'max_heap_table_size\' max_heap_table_size
mysql_variable \'log_bin\' log_bin
mysql_status \'Max_used_connections\' max_used_connections
if [ $major_version = 3.23 ] ; then
mysql_variable \'record_buffer\' read_buffer_size
mysql_variable \'record_rnd_buffer\' read_rnd_buffer_size
mysql_variable \'sort_buffer\' sort_buffer_size
fi
if [ $log_bin = ON ] ; then
mysql_variable \'binlog_cache_size\' binlog_cache_size
else
binlog_cache_size=0
fi
if [ $max_heap_table_size -le $tmp_table_size ] ; then
effective_tmp_table_size=$max_heap_table_size
else
effective_tmp_table_size=$tmp_table_size
fi
per_thread_buffers=$(echo
($read_buffer_size+$read_rnd_buffer_size+$sort_buffer_size+$thread_stack+$join_buffer_size+$binlog_cache_size)*$max_connections
| bc -l)
per_thread_max_buffers=$(echo
($read_buffer_size+$read_rnd_buffer_size+$sort_buffer_size+$thread_stack+$join_buffer_size+$binlog_cache_size)*$max_used_connections
| bc -l)
mysql_variable \'innodb_buffer_pool_size\' innodb_buffer_pool_size
if [ -z $innodb_buffer_pool_size ] ; then
innodb_buffer_pool_size=0
fi
mysql_variable \'innodb_additional_mem_pool_size\'
innodb_additional_mem_pool_size
if [ -z $innodb_additional_mem_pool_size ] ; then
innodb_additional_mem_pool_size=0
fi
mysql_variable \'innodb_log_buffer_size\' innodb_log_buffer_size
if [ -z $innodb_log_buffer_size ] ; then
innodb_log_buffer_size=0
fi
mysql_variable \'key_buffer_size\' key_buffer_size
mysql_variable \'query_cache_size\' query_cache_size
if [ -z $query_cache_size ] ; then
query_cache_size=0
fi
global_buffers=$(echo
$innodb_buffer_pool_size+$innodb_additional_mem_pool_size+$innodb_log_buffer_size+$key_buffer_size+$query_cache_size
| bc -l)
max_memory=$(echo
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 14:52, Edson Brandi escreveu:
Em 11 de julho de 2012 14:33, Marcelo Gondim gon...@bsdinfo.com.br escreveu:
Será que sem querer descobri algo interessante? rsrsrsrsrs
Marcelo,
Estava dando uma olhada em como o mysql tuning primer
(https://launchpad.net/mysql-tuning-primer/), chega nos números.
Pelo que vi ele não está usando nenhuma variavel do sistema
operacional, e esta fazendo praticamente todas as contas tendo como
input variaveis do mysql.
Com base nesta lógica de calculo a unica explicação que vejo pros
numeros estarem diferentes é se estas variaveis forem diferentes entre
o seu mysql rodando no linux e o seu mysql rodando no FreeBSD. Não me
parece ser algo relacionado ao sistema operacional.
Pois é mas se pegar as confs copiar de um pra outro usando as mesmas
variáveis e só mudando o max_connection já dá uma grande diferença.
Também quero encontrar uma solução para isso. Também pensei no seguinte:
e se o tuning-primer não tivesse funcionando corretamente no FreeBSD, os
valores estivesses errados e fossem proximos dos do Linux. Então tudo
deveria funcionar normalmente mas não funciona. Quando estouro com o
max_connection passa à dar esse erro aqui:
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
Se procurar no google por esse erro vamos ver que muita gente tenta resolver
isso mas tudo que li e tentei não consegui resolver. Só descobri que se tento
usar os 4000 começa à dar os erros de acesso que postei acima.
Aí mais à frente descobri essa página:
http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html
Onde no final está escrito assim:
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.
A unica informação que ele usa do sistema operacional é a quantidade de
memoria:
get_system_info () {
export OS=$(uname)
# Get information for various UNIXes
if [ $OS = 'Darwin' ]; then
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(sysctl -n hw.memsize)
export duflags=''
elif [ $OS = 'FreeBSD' ] || [ $OS = 'OpenBSD' ]; then
## On FreeBSD must be root to locate sockets.
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(sysctl -n hw.realmem)
export duflags=''
elif [ $OS = 'Linux' ] ; then
## Includes SWAP
## export physical_memory=$(free -b | grep -v buffers | awk
'{ s += $2 } END { printf(%.0f\n, s ) }')
ps_socket=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9
}' | head -1)
found_socks=$(netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }')
export physical_memory=$(awk '/^MemTotal/ { printf(%.0f,
$2*1024 ) }' /proc/meminfo)
export duflags='-b'
elif [ $OS = 'SunOS' ] ; then
ps_socket=$(netstat -an | awk '/mysql(.*)?.sock/ { print $5 }'
| head -1)
found_socks=$(netstat -an | awk '/mysql(.*)?.sock/ { print $5 }')
export physical_memory=$(prtconf | awk '/^Memory\ size:/ {
print $3*1048576 }')
fi
if [ -z $(which bc) ] ; then
echo Error: Command line calculator 'bc' not found!
exit
fi
}
Colei a função que calcula a alocação de memoria abaixo:
total_memory_used () {
## -- Total Memory Usage -- ##
cecho MEMORY USAGE boldblue
mysql_variable \'read_buffer_size\' read_buffer_size
mysql_variable \'read_rnd_buffer_size\' read_rnd_buffer_size
mysql_variable \'sort_buffer_size\' sort_buffer_size
mysql_variable \'thread_stack\' thread_stack
mysql_variable \'max_connections\' max_connections
mysql_variable \'join_buffer_size\' join_buffer_size
mysql_variable \'tmp_table_size\' tmp_table_size
mysql_variable \'max_heap_table_size\' max_heap_table_size
mysql_variable \'log_bin\' log_bin
mysql_status \'Max_used_connections\' max_used_connections
if [ $major_version = 3.23 ] ; then
mysql_variable \'record_buffer\' read_buffer_size
mysql_variable \'record_rnd_buffer\' read_rnd_buffer_size
mysql_variable \'sort_buffer\' sort_buffer_size
fi
if [ $log_bin = ON ] ; then
mysql_variable \'binlog_cache_size\' binlog_cache_size
else
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 15:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: 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. Marcelo, Esses comportamentos exóticos são divertidos de se debugar rs , infelizmente nem sempre é rápido ;) Bom, pelo que vc nos disse até agora o hardware é exatamente o mesmo, rodando versões 64 bits do sistema operacional e do MySQL (mesmas versões?), ambos com as mesmas configurações na sessão [mysqld] do my.cnf. Correto? O binário que você está usando no linux é pré compilado pela mySQL AB, ou foi compilado manualmente por você? Pode nos enviar a saida de um ldd no binário do mysqld em cada um dos seus 2 ambientes? [ ]'s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 15:38, Edson Brandi escreveu: Em 11 de julho de 2012 15:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: 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. Marcelo, Esses comportamentos exóticos são divertidos de se debugar rs , infelizmente nem sempre é rápido ;) rsrsr pois é, mas é legal descobrir esse tipo de coisa porque com certeza vai servir pra alguém algum dia. rsrsrs tipo no meu dia a dia nunca precisei usar valores de 1000 conexões na base. Aqui os sistemas são tranquilos. 1000 conexões concorrentes no mysql é muita coisa aqui pra gente. Mas no manicomio-share (site de torrents da gente) é diferente porque faz parte do tipo de acesso em sites de torrents fechados. Se fosse um site de torrent aberto não teríamos a necessidade de um announce mas também tudo que é muito liberal acaba perdendo a qualidade. :D Bom, pelo que vc nos disse até agora o hardware é exatamente o mesmo, rodando versões 64 bits do sistema operacional e do MySQL (mesmas versões?), ambos com as mesmas configurações na sessão [mysqld] do my.cnf. Correto? Isso mesmo. O binário que você está usando no linux é pré compilado pela mySQL AB, ou foi compilado manualmente por você? Quando preciso usar Linux eu uso o Debian, nesse caso instalei o pacote do mysql que vem na distro que é a versão 5.1. Tentei no FreeBSD também com o MySQL 5.5 mas não adiantou, aconteceu a mesma coisa. Pode nos enviar a saida de um ldd no binário do mysqld em cada um dos seus 2 ambientes? Sim lógico. :) o que precisarem pra gente tentar descobrir isso. FreeBSD: # ldd /usr/local/libexec/mysqld /usr/local/libexec/mysqld: librt.so.1 = /usr/lib/librt.so.1 (0x280c4e000) libz.so.6 = /lib/libz.so.6 (0x280e53000) libwrap.so.6 = /usr/lib/libwrap.so.6 (0x28106f000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x281278000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x28149d000) libm.so.5 = /lib/libm.so.5 (0x2817be000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2819e1000) libthr.so.3 = /lib/libthr.so.3 (0x281bef000) libc.so.7 = /lib/libc.so.7 (0x281e13000) Debian: # ldd /usr/sbin/mysqld linux-vdso.so.1 = (0x7fff451b1000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fc0e1698000) libz.so.1 = /usr/lib/libz.so.1 (0x7fc0e1481000) libwrap.so.0 = /lib/libwrap.so.0 (0x7fc0e1277000) libdl.so.2 = /lib/libdl.so.2 (0x7fc0e1073000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x7fc0e0e3c000) libnsl.so.1 = /lib/libnsl.so.1 (0x7fc0e0c23000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fc0e090f000) libm.so.6 = /lib/libm.so.6 (0x7fc0e068d000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fc0e0476000) libc.so.6 = /lib/libc.so.6 (0x7fc0e0114000) /lib64/ld-linux-x86-64.so.2 (0x7fc0e2476000) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
O Brandi é o cara... se ele nao ajudar a resolver essa bronca tamo tudo lascado, ehehe daí ate eu vou voltar pro linux, Eu na minha tosquice, acho que o tipo de thread usada tem que ser mais testado... outra coisa marcelo, vc compilou o mysql no ports com BUILD_OPTIMIZED E BUILD_STATIC ?? essa do static é importante, Faz o teste de rodar o bin do linux la no bsd.. uma pergunta que lembrei agora, la no linux, quando esta com as 4000 conexoes, e vc da um ps ax, aparecem 4000 processos de mysql ??? ou apenas um ou poucos abs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 16:07, Leonardo Augusto escreveu: O Brandi é o cara... se ele nao ajudar a resolver essa bronca tamo tudo lascado, ehehe daí ate eu vou voltar pro linux, hehehe to torcendo pra isso srsrrsrsrsrs Eu na minha tosquice, acho que o tipo de thread usada tem que ser mais testado... outra coisa marcelo, vc compilou o mysql no ports com BUILD_OPTIMIZED E BUILD_STATIC ?? essa do static é importante, Sempre compilo com o BUILD_OPTIMIZED mas não testei com fazendo ele estático não. Eu tentei até usar o WITH_LINUXTHREADS=yes mas ele está marcado no ports como não compilável mais. Faz o teste de rodar o bin do linux la no bsd.. Pior, vai que funciona mas tipo não gostaria de rodar o mysql assim não. Se posso rodar ele nativo prefiro ele nativo. :) uma pergunta que lembrei agora, la no linux, quando esta com as 4000 conexoes, e vc da um ps ax, aparecem 4000 processos de mysql ??? ou apenas um ou poucos Sempre os mesmos processos. Nunca vi mais que esses aí não: No Freeba: 3710 ?? Is 0:00.00 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --socket=/tmp/mysql.sock --p 3748 ?? I 0:02.59 /usr/local/libexec/mysqld --defaults-extra-file=/var/db/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/ No Linux: 26731 ?S 0:00 /bin/sh /usr/bin/mysqld_safe 26864 ?Sl 2514:55 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306 26865 ?S 0:00 \_ logger -t mysqld -p daemon.error abs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 16:18, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 11/07/2012 16:07, Leonardo Augusto escreveu: O Brandi é o cara... se ele nao ajudar a resolver essa bronca tamo tudo lascado, ehehe daí ate eu vou voltar pro linux, hehehe to torcendo pra isso srsrrsrsrsrs Ta certo... :) Eu vou subir um ambiente em casa para fazer alguns testes , o difícil vai ser arrumar uma forma de estressar em laboratório estas 4.000 conexões :\ [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 16:36, Edson Brandi escreveu: Em 11 de julho de 2012 16:18, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 11/07/2012 16:07, Leonardo Augusto escreveu: O Brandi é o cara... se ele nao ajudar a resolver essa bronca tamo tudo lascado, ehehe daí ate eu vou voltar pro linux, hehehe to torcendo pra isso srsrrsrsrsrs Ta certo... :) Eu vou subir um ambiente em casa para fazer alguns testes , o difícil vai ser arrumar uma forma de estressar em laboratório estas 4.000 conexões :\ ixi é mesmo. A gente conseguiu aqui porque nosso site consome isso aí. rsrsrsrs Eu não programo mas tipo se fizer uma página index.php com uma consulta na base, poderia usar o ab do apache pra solicitar as 4000 conexões. Seria uma idéia. ;) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
2012/7/11 Marcelo Gondim gon...@bsdinfo.com.br: Em 11/07/2012 11:50, Leonardo Augusto escreveu: hehe isso do mysql ta virando pessoal ja. vamos dar um jeito nisso. não é? rsrsrsr eu so nao posso fazer mais testes em funcao da minha condicao de deitado temporariamenre. passa as configs do kernel e o my.cnf que usou, o sysctl -a grep kern tb e interessante. Pra testar eu peguei my-huge mesmo e só adicionei o max_connections sem acessos à base. Só pra efeito de teste mesmo. Agora o do Linux que tá em produção é esse aqui: [mysqld] open-files-limit = 20 user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language= /usr/share/mysql/english skip-external-locking bind-address= 127.0.0.1 low_priority_updates= 1 concurrent_insert = 2 key_buffer_size = 2G max_allowed_packet = 512M thread_stack= 512K thread_cache_size = 128 myisam-recover = BACKUP max_connections= 4000 table_cache= 5000 thread_concurrency = 24 query_cache_limit = 16M query_cache_size= 128M expire_logs_days= 10 max_binlog_size = 100M 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
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. -- Atenciosamente, Antônio Pessoa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 16:56, Luiz Otavio O Souza escreveu: 2012/7/11 Marcelo Gondim gon...@bsdinfo.com.br: Em 11/07/2012 11:50, Leonardo Augusto escreveu: hehe isso do mysql ta virando pessoal ja. vamos dar um jeito nisso. não é? rsrsrsr eu so nao posso fazer mais testes em funcao da minha condicao de deitado temporariamenre. passa as configs do kernel e o my.cnf que usou, o sysctl -a grep kern tb e interessante. Pra testar eu peguei my-huge mesmo e só adicionei o max_connections sem acessos à base. Só pra efeito de teste mesmo. Agora o do Linux que tá em produção é esse aqui: [mysqld] open-files-limit = 20 user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language= /usr/share/mysql/english skip-external-locking bind-address= 127.0.0.1 low_priority_updates= 1 concurrent_insert = 2 key_buffer_size = 2G max_allowed_packet = 512M thread_stack= 512K thread_cache_size = 128 myisam-recover = BACKUP max_connections= 4000 table_cache= 5000 thread_concurrency = 24 query_cache_limit = 16M query_cache_size= 128M expire_logs_days= 10 max_binlog_size = 100M 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. Oi Luiz eu fiz isso também e mesmo usando as mesmas confs dava a diferença. Tentei usando as mesmas confs, tentei fazendo ajustes diferenciados e em ambos os casos o problema apareceu. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
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. Agora a pergunta é, seu servidor realmente precisa aceitar 4000 conexões simultaneas ? não convém dividir uma carga dessas ? Isso é puramente uma questão de configuração do MySQL e não tem relação com o SO (FreeBSD). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Bom, Peguei 2 VMs aqui idênticas em termos de hardware virtual (rs), rodando sobre VMWare ESXi 5.0, configuradas com 4 Gb de RAM... Uma rodando: FreeBSD keyserver.fug.com.br 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 e na outra: Linux server01.ebrandi.eti.br 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012 x86_64 x86_64 x86_64 GNU/Linux Não tinha uma VM com o FreeBSD 64 Bits aqui para testar... A configuração e a versão do mysql é a mesma nas 2 VMs. Os cálculos do consumo teórico de memoria em cada uma delas informado MySQL Tuning Primer está abaixo, os numeros são bem parecidos, e vai de encontro com aquela impressão que eu tinha de que o calculo do Tuning Primer não olha nada do sistema operacional. O proximo passo vai ser fazer um teste real de carga... ### FreeBSD ### * max_connections=1 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 154 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=10 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 26 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 178 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=100 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 268 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 420 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=1000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2.62 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 2.77 G Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=4000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 1.00 G Max memory limit exceeds 90% of physical memory Linux * max_connections=1 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 154 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=10 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 27 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 179 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=100 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 275 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 427 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=1000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2.68 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 2.83 G Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=4000 MEMORY USAGE Max Memory Ever Allocated : 157 M Configured Max Per-thread Buffers : 10.74 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.89 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
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
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 17:35, Luiz Otavio O Souza escreveu: Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Sim. Isso também sei rsrsrs no freeba em /var/db/mysql/ e no Debian em /etc/mysql/ Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Queria muito que fosse isso. Se fosse isso quando eu colocasse 4000 conexões não daria o erro que está dando. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 17:55, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 17:35, Luiz Otavio O Souza escreveu: Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Sim. Isso também sei rsrsrs no freeba em /var/db/mysql/ e no Debian em /etc/mysql/ Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Queria muito que fosse isso. Se fosse isso quando eu colocasse 4000 conexões não daria o erro que está dando. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Será que clusterizar o mysql, distribuindo as conexões não teria um rendimento melhor ? Sei que não resolve o problema esposto na thread, mais ainda assim logo irá chegar no limite de hardware mesmo no linux e hoje o linux aguenta as 4K de conexões e depois disso qual será o OS a tolerar ? Eu particularmente utilizo PostgreSQL e o no passado coloquei 2048 conexões apenas para brincar e um script PHP com inserts em um quad-core com 4G de ram e não tive problemas depois deixei de lado pois 2048 conexões já é algo realmente grande para ver se a configs de tunings que utilizo irá satisfazer minhas necessidades em algum projeto que venha a ter. Está facil de manipular o db utilizado pela aplicação em questão para trocar o DB ? -- :=)(=: Flamers /dev/null !!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 17:55, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 17:35, Luiz Otavio O Souza escreveu: Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Sim. Isso também sei rsrsrs no freeba em /var/db/mysql/ e no Debian em /etc/mysql/ Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Queria muito que fosse isso. Se fosse isso quando eu colocasse 4000 conexões não daria o erro que está dando. Mas você está apavorado com o consumo de memória? É isso? O script faz um cálculo em cima do máximo de conexões 4000 x per-thread dará quanto ele poderá (não que irá) alocar de memória. Não te apavora com isso, só se realmente chegar em 4000 aí sim você terá um problemão... hehehe. Veja: max_conn=10 / Max Per-thread Buffers : 26 MB / max total (per thread*max_conn + global)=178M max_conn=100 / Max Per-thread Buffers : 268 MB / max total (per thread*max_conn + global)=420M max_conn=1000 / Max Per-thread Buffers : 2,77 GB / max total (per thread*max_conn + global)=3,74GB Eu tenho um servidor de um portal *bem* acessado rodando mysql com máximo de 100 conexões, não preciso mais do que isso -- só quando há um lock em alguma tabela que é lida por muitas consultas... aí sim dá problema de conexão. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 18:05, Eduardo Schoedler lis...@esds.com.br escreveu: Mas você está apavorado com o consumo de memória? É isso? Eduardo, Se eu entendi o problema do Marcelo, na pratica o que está acontecendo é que o mysqld não está conseguindo alocar a memoria necessária para ter 4.000 conexões ativas. Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 18:16, Edson Brandi ebra...@fugspbr.org escreveu: Se eu entendi o problema do Marcelo, na pratica o que está acontecendo é que o mysqld não está conseguindo alocar a memoria necessária para ter 4.000 conexões ativas. Se realmente precisar aguentar as 4000 conexões simultâneas, vai precisar de mais memória -- ou então baixar alguns parâmetros que interferem diretamente no consumo por thread, além dos valores globais. Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Mesmo? Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. Pois é, você eliminou a variável do sistema operacional nesse script. Por isso fiquei sem entender... -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 18:23, Eduardo Schoedler lis...@esds.com.br escreveu: Se realmente precisar aguentar as 4000 conexões simultâneas, vai precisar de mais memória -- ou então baixar alguns parâmetros que interferem diretamente no consumo por thread, além dos valores globais. A principio 12 Gb é suficiente para as 4.000 conexões Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Mesmo? Sim, ta la no primeiro email dele o output do script no FreeBSD dele com o calculo para 4.000 conexões: 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 : 13.00 G Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. Pois é, você eliminou a variável do sistema operacional nesse script. Por isso fiquei sem entender... Então, é o que eu disse antes, se pelo calculo teórico a maquina tem memoria suficiente, o problema está em porque raios o mysqld não consegue usar a memoria se teoricamente os parâmetros do kernel para permitir o uso de mais de 512Mb estão corretos :) Esse teste pratico eu ainda não tive tempo de fazer. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
2012/7/11 Marcelo Gondim gon...@bsdinfo.com.br: Em 11/07/2012 16:07, Leonardo Augusto escreveu: O Brandi é o cara... se ele nao ajudar a resolver essa bronca tamo tudo lascado, ehehe daí ate eu vou voltar pro linux, hehehe to torcendo pra isso srsrrsrsrsrs Eu na minha tosquice, acho que o tipo de thread usada tem que ser mais testado... outra coisa marcelo, vc compilou o mysql no ports com BUILD_OPTIMIZED E BUILD_STATIC ?? essa do static é importante, Sempre compilo com o BUILD_OPTIMIZED mas não testei com fazendo ele estático não. Eu tentei até usar o WITH_LINUXTHREADS=yes mas ele está marcado no ports como não compilável mais. Faz o teste de rodar o bin do linux la no bsd.. Pior, vai que funciona mas tipo não gostaria de rodar o mysql assim não. Se posso rodar ele nativo prefiro ele nativo. :) uma pergunta que lembrei agora, la no linux, quando esta com as 4000 conexoes, e vc da um ps ax, aparecem 4000 processos de mysql ??? ou apenas um ou poucos Sempre os mesmos processos. Nunca vi mais que esses aí não: No Freeba: 3710 ?? Is 0:00.00 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --socket=/tmp/mysql.sock --p 3748 ?? I 0:02.59 /usr/local/libexec/mysqld --defaults-extra-file=/var/db/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/ No Linux: 26731 ?S 0:00 /bin/sh /usr/bin/mysqld_safe 26864 ?Sl 2514:55 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306 26865 ?S 0:00 \_ logger -t mysqld -p daemon.error Engracado isso, no meu tempo de linux, acho que era ate 1999, cada conexao do mysql criava um novo processo, pq acho que as threads desse lixo(kkk) eram tipo um fork com memoria compartilhada, aí ficavam 300 mil processos la do mysql Agora entao eles devem ter mudado isso, se no caso, fica apenas alguns processos aparecendo :) Sabe o que nao gosto no linux ? se vc aprende a instalar configurar o centos por exemplo, ai pega um debian, ou um slack ou sei la o que, se ferra todo, pq sempre tem alguma coisa ou algum pacote que fica num diretorio diferente ou coisa do tipo, que raiva disso, vai se ferra linux xupeta maldito, a unica coisa que sinto saudade desse pinguim sem nocao é o IPTRAF, aquilo era legal os que chegam perto do bsd ainda nao sao legais como aquele. pelo que li quando lancaram o freebsd 7 pra cima, a reformulacao das threads foi muito boa, melhorou muita das versoes anteriores e pelo que entendi bem melhor que do linux, nao entendo como pode estar dando esse xabu ai... no fundo espero que seja problema de BIOS mesmo, eheh pq aí é facil resolver, pega a 12 e pronto, kk só rindo pra nao xorar - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11 de julho de 2012 17:55, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 17:35, Luiz Otavio O Souza escreveu: Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Sim. Isso também sei rsrsrs no freeba em /var/db/mysql/ e no Debian em /etc/mysql/ Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Queria muito que fosse isso. Se fosse isso quando eu colocasse 4000 conexões não daria o erro que está dando. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Opa! To extremamente encucado com esse causo. Testou já compilar o mysql com BUILD_STATIC ? -- Matheus Conceição - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 17:45, Edson Brandi escreveu: Bom, Peguei 2 VMs aqui idênticas em termos de hardware virtual (rs), rodando sobre VMWare ESXi 5.0, configuradas com 4 Gb de RAM... Uma rodando: FreeBSD keyserver.fug.com.br 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 e na outra: Linux server01.ebrandi.eti.br 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012 x86_64 x86_64 x86_64 GNU/Linux Não tinha uma VM com o FreeBSD 64 Bits aqui para testar... A configuração e a versão do mysql é a mesma nas 2 VMs. Os cálculos do consumo teórico de memoria em cada uma delas informado MySQL Tuning Primer está abaixo, os numeros são bem parecidos, e vai de encontro com aquela impressão que eu tinha de que o calculo do Tuning Primer não olha nada do sistema operacional. O proximo passo vai ser fazer um teste real de carga... ### FreeBSD ### * max_connections=1 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 154 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=10 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 26 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 178 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=100 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 268 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 420 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=1000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2.62 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 2.77 G Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=4000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 1.00 G Max memory limit exceeds 90% of physical memory Linux * max_connections=1 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 154 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=10 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 27 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 179 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=100 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 275 M Configured Max Global Buffers : 152 M Configured Max Memory Limit : 427 M Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=1000 MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 2.68 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 2.83 G Physical Memory : 3.74 G Max memory limit seem to be within acceptable norms * max_connections=4000 MEMORY USAGE Max Memory Ever Allocated : 157 M Configured Max Per-thread Buffers : 10.74 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.89 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Opa Edson, Me manda o seu my.cnf de teste pra eu jogar na VM que fiz aqui de 64 bits. Pra eu ver que bicho vai dar. :) Vai que o problema é por ser 64 bits. Bem temos que testar tudo e 32 bits tem que endereçar menos mesmo. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 18:16, Edson Brandi escreveu: Em 11 de julho de 2012 18:05, Eduardo Schoedler lis...@esds.com.br escreveu: Mas você está apavorado com o consumo de memória? É isso? Eduardo, Se eu entendi o problema do Marcelo, na pratica o que está acontecendo é que o mysqld não está conseguindo alocar a memoria necessária para ter 4.000 conexões ativas. Sim. A mesma conf que eu usava em um Linux 64 bits com 16Gb de ram não estourava nada. Mas quando peguei um FreeBSD 9 e 8.3 joguei a base e usei a mesma conf do outro servidor, o mesmo dizia que eu precisava de uns 70Gb pra ter as 4000 conexões e quando as conexões chegavam perto dos 4000 já dava erro de conexão no mysql dizendo que não tinha ram, sendo que no servidor novo haviam 24Gb de ram. Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Isso mesmo. :) Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. Mas tem uma diferença no seu teste. Você tá usando um FreeBSD 32 bits e um Linux 64 bits. Só aí já existe uma diferença. ;) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 18:23, Eduardo Schoedler escreveu: Em 11 de julho de 2012 18:16, Edson Brandi ebra...@fugspbr.org escreveu: Se eu entendi o problema do Marcelo, na pratica o que está acontecendo é que o mysqld não está conseguindo alocar a memoria necessária para ter 4.000 conexões ativas. Se realmente precisar aguentar as 4000 conexões simultâneas, vai precisar de mais memória -- ou então baixar alguns parâmetros que interferem diretamente no consumo por thread, além dos valores globais. Pois é eu tentei abaixar alguns valores mas não foi isso que me intrigou. Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Mesmo? Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. Pois é, você eliminou a variável do sistema operacional nesse script. Por isso fiquei sem entender... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 18:36, Edson Brandi escreveu: Em 11 de julho de 2012 18:23, Eduardo Schoedler lis...@esds.com.br escreveu: Se realmente precisar aguentar as 4000 conexões simultâneas, vai precisar de mais memória -- ou então baixar alguns parâmetros que interferem diretamente no consumo por thread, além dos valores globais. A principio 12 Gb é suficiente para as 4.000 conexões Para ajudar na confusão, o output do script mysql tuning primer (https://launchpad.net/mysql-tuning-primer/) no servidor FreeBSD do Marcelo diz que para ter 4.000 conexões ele precisa de MUITO mais RAM do que no Linux. Mesmo? Sim, ta la no primeiro email dele o output do script no FreeBSD dele com o calculo para 4.000 conexões: 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 : 13.00 G Eu fiz um teste com o script aqui rodando em VMs iguais com Linux e FreeBSD (setup vanilla em ambas, sem nenhum tuning), e a quantidade de memoria reportada é sempre semelhante entre os sistemas. Pois é, você eliminou a variável do sistema operacional nesse script. Por isso fiquei sem entender... Então, é o que eu disse antes, se pelo calculo teórico a maquina tem memoria suficiente, o problema está em porque raios o mysqld não consegue usar a memoria se teoricamente os parâmetros do kernel para permitir o uso de mais de 512Mb estão corretos :) Esse teste pratico eu ainda não tive tempo de fazer. [ ]´s Brandi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Opa Edson, Instalei uma VM aqui com o FreeBSD 9 amd64. Copiei o my-huge.cnf como exemplo e só adicionei o max_connections = 4000 Rodei o tuning-primer e a saída é essa: 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 Vou pegar uma VM 32 bits e fazer a mesma coisa e aí posto novamente. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Em 11/07/2012 21:39, Matheus Weber da Conceição escreveu: Em 11 de julho de 2012 17:55, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 11/07/2012 17:35, Luiz Otavio O Souza escreveu: Lembrando que o arquivo 'my.cnf' no FreeBSD deve ficar no diretório /var/db/mysql e não no /etc (e nem no /usr/local/etc). Sim. Isso também sei rsrsrs no freeba em /var/db/mysql/ e no Debian em /etc/mysql/ Talves o mysql tenha ignorado o my.cnf se você não copiou ele no diretório correto (e por isso você não viu diferença até agora). Queria muito que fosse isso. Se fosse isso quando eu colocasse 4000 conexões não daria o erro que está dando. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Opa! To extremamente encucado com esse causo. Testou já compilar o mysql com BUILD_STATIC ? Ainda não mas vou testar também. Mas antes vou testar em uma VM de 32 bits. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD
Marcelo, O problema está nessa configuração ai do mysql que vc esta usando... Refiz um teste aqui com o FreeBSD 64 bits... Se eu uso o /usr/local/share/mysql/my-huge.cnf como sendo o meu /var/db/mysql/my.cnf e seto o max_connections=4000 , o output do tunning primer é o que vc está obtendo: MEMORY USAGE Max Memory Ever Allocated : 572 M Configured Max Per-thread Buffers : 48.21 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 48.76 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Se eu uso o mysqld com a configuração default (default = não existe o my.cnf), e adiciono apenas o parâmetro para 4.000 conexões (o arquivo vai ficar com apenas 2 linhas): [mysqld] max_connections=4000 O output do tuning-primer.sh é o que eu tinha enviado antes (muito semelhante no linux e no FreeBSD): MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 3.74G Max memory limit exceeds 90% of physical memory Se eu uso o mesmo arquivo de configuração (/usr/local/share/mysql/my-huge.cnf ) no servidor Linux, fazendo os ajustes necessários para que o mysqld rode, visto que aqui no meu lab o daemon no linux nem sobe com este arquivo de configuração copiado do FreeBSD se vc não adicionar as linhas abaixo na sessão [mysqld]: datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql O resultado é o mesmo que no FreeBSD: MEMORY USAGE Max Memory Ever Allocated : 584 M Configured Max Per-thread Buffers : 48.46 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 49.00 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Ou seja, acho pouco provável que o seu servidor Linux e o seu servidor FreeBSD estejam rodando exatamente com a mesma configuração no MySQL (este my-huge.cnf)... Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Diferença absurda do mysql no Linux para o do FreeBSD [RESOLVIDO]
Em 12/07/2012 00:24, Edson Brandi escreveu: Marcelo, O problema está nessa configuração ai do mysql que vc esta usando... Refiz um teste aqui com o FreeBSD 64 bits... Se eu uso o /usr/local/share/mysql/my-huge.cnf como sendo o meu /var/db/mysql/my.cnf e seto o max_connections=4000 , o output do tunning primer é o que vc está obtendo: MEMORY USAGE Max Memory Ever Allocated : 572 M Configured Max Per-thread Buffers : 48.21 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 48.76 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Se eu uso o mysqld com a configuração default (default = não existe o my.cnf), e adiciono apenas o parâmetro para 4.000 conexões (o arquivo vai ficar com apenas 2 linhas): [mysqld] max_connections=4000 O output do tuning-primer.sh é o que eu tinha enviado antes (muito semelhante no linux e no FreeBSD): MEMORY USAGE Max Memory Ever Allocated : 154 M Configured Max Per-thread Buffers : 10.49 G Configured Max Global Buffers : 152 M Configured Max Memory Limit : 10.64 G Physical Memory : 3.74G Max memory limit exceeds 90% of physical memory Se eu uso o mesmo arquivo de configuração (/usr/local/share/mysql/my-huge.cnf ) no servidor Linux, fazendo os ajustes necessários para que o mysqld rode, visto que aqui no meu lab o daemon no linux nem sobe com este arquivo de configuração copiado do FreeBSD se vc não adicionar as linhas abaixo na sessão [mysqld]: datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql O resultado é o mesmo que no FreeBSD: MEMORY USAGE Max Memory Ever Allocated : 584 M Configured Max Per-thread Buffers : 48.46 G Configured Max Global Buffers : 560 M Configured Max Memory Limit : 49.00 G Physical Memory : 3.74 G Max memory limit exceeds 90% of physical memory Ou seja, acho pouco provável que o seu servidor Linux e o seu servidor FreeBSD estejam rodando exatamente com a mesma configuração no MySQL (este my-huge.cnf)... Edson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Achei o maldito. Interessante que na configuração original ele está em K. Em algum momento eu devo ter colocado esse cara pra M pra tunar algo. Esse cara aqui que descacetou tudo: read_rnd_buffer_size = 8M Quando adiciono ele tanto no Linux quanto no FreeBSD com valor alto tipo 8M tudo sobe. Com valores em K ou sem ele o consumo é o esperado. Ufa! Resolvido. Edson valeu mesmo e realmente está comprovado que não existe a diferença entre o Linux e o FreeBSD e sim foi um erro meu nos testes. Agora já estou com esperanças novamente de migrar o servidor Linux para FreeBSD rsrsrsrsr Galera vou abrir outra thread para discutirmos o tunning para esse tipo de servidor com muito acesso. :) Mas vou fazer isso mais tarde porque são 01:39 e não aguento mais por hoje ahhaahha Obrigado à todos mais uma vez e me desculpem pelo erro de K e M rsrsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
