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 [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á
