Re: [FUG-BR] Problema estranho com sessão ssh e parece ser buffer
On 12-05-2015 13:10, Nenhum_de_Nos wrote: On Tue, 12 May 2015 11:28:12 -0300 Marcelo Gondim gon...@bsdinfo.com.br wrote: Valeu Eduardo, vou ver aqui. O estranho é porque isso só acontece com acessos de dentro daqui da rede local e quando acesso de casa o problema não acontece. Vou fazer um teste aqui :) Gondim, isso me lembra problema com o roteador (ou os roteadores) no caminho e não no servidor (cliente que abre a conexão ssh, servidor é quem a recebe). Já vi roteadores destes simples, de operadora ou esses dlink's simples da vida, terem sua memória para conexões esgotada. Daí eles começam a sacrificar as conexões já existentes. Com roteador destes, não consigo deixar um ssh aberto sem que aconteça timed out. Ele pode sacrificar a conexão por muito tempo sem atividade, ou por ter sessão demais. Não é o mesmo comportamento da tela não atualizar, mas pode ajudar no caso das conexões reiniciadas pelo peer :) matheus Opa Matheus, To desconfiado aqui da máquina proxy. Ela é bem antiga e só dá o problema atrás dela. Vou tentar trocar ela aqui pra ver se para isso. []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema estranho com sessão ssh e parece ser buffer
On Tue, 12 May 2015 11:28:12 -0300 Marcelo Gondim gon...@bsdinfo.com.br wrote: Valeu Eduardo, vou ver aqui. O estranho é porque isso só acontece com acessos de dentro daqui da rede local e quando acesso de casa o problema não acontece. Vou fazer um teste aqui :) Gondim, isso me lembra problema com o roteador (ou os roteadores) no caminho e não no servidor (cliente que abre a conexão ssh, servidor é quem a recebe). Já vi roteadores destes simples, de operadora ou esses dlink's simples da vida, terem sua memória para conexões esgotada. Daí eles começam a sacrificar as conexões já existentes. Com roteador destes, não consigo deixar um ssh aberto sem que aconteça timed out. Ele pode sacrificar a conexão por muito tempo sem atividade, ou por ter sessão demais. Não é o mesmo comportamento da tela não atualizar, mas pode ajudar no caso das conexões reiniciadas pelo peer :) matheus -- We will call you Cygnus, the God of balance you shall be. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, 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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd LooS pqp :D hahaha vou testar isso hoje ainda. Pode ser a luz heim! :D Valeu!!! []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 15:40, Rafael Henrique Faria wrote: Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. Boa tarde Rafael, Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo fazer essa migração, será meu próximo passo. O ambiente hoje é em php. []'s 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd LooS pqp :D hahaha vou testar isso hoje ainda. Pode ser a luz heim! :D Valeu!!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 16:48, Fabricio Lima wrote: PHP puro ou com APC, eAccelerator ou FPM? Recomendo ativar um deles... vai fazer cache de compilaçao do php.. grandes ganhos. nginx é imprescindivel.. incrivel estar funcionando no linux atual.. mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no apache.. ja evitei de migrar uns tb. legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar mod_security... em algo q ja ta rodando. proximo passo, manda um netstat -m com seu ambiente tunado pra vermos como está, pra ver se da pra identificar ONDE está faltando tunar. Opa Fabricio, PHP com memcache. Pois é sempre fiquei indignado do site rodar bem e rápido em um Debian com kernel generic e não conseguir rodá-lo em um FreeBSD. :( [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 16:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 15:40, Rafael Henrique Faria wrote: Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. Boa tarde Rafael, Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo fazer essa migração, será meu próximo passo. O ambiente hoje é em php. []'s 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, Luiz - Histórico:
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd LooS pqp :D hahaha vou testar isso hoje ainda. Pode ser a luz heim! :D Valeu!!! []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Rafael Henrique da Silva Faria - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
PHP puro ou com APC, eAccelerator ou FPM? Recomendo ativar um deles... vai fazer cache de compilaçao do php.. grandes ganhos. nginx é imprescindivel.. incrivel estar funcionando no linux atual.. mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no apache.. ja evitei de migrar uns tb. legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar mod_security... em algo q ja ta rodando. proximo passo, manda um netstat -m com seu ambiente tunado pra vermos como está, pra ver se da pra identificar ONDE está faltando tunar. [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 16:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 15:40, Rafael Henrique Faria wrote: Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. Boa tarde Rafael, Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo fazer essa migração, será meu próximo passo. O ambiente hoje é em php. []'s 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é quem determina o limita para cada socket criado no momento em que ela chama o listen(2) (veja o parâmetro backlog). No apache você pode setar isso com o parametro ListenBacklog (detalhes em http://httpd.apache.org/docs/2.2/mod/mpm_common.html). O uso do accept filters pode ajudar, mas além de carregar os modulos você precisa ativar eles no apache, veja essa thread (como um exemplo): https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/ HTH, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd LooS pqp :D hahaha vou testar isso hoje ainda. Pode ser a luz heim!
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra nos? enquanto o DNS está virando gradualmente na internet, o site chega a abrir? e so depois q 'frita' q passa a nao abrir mais? quanto tem de memoria? [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 17:04, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 16:48, Fabricio Lima wrote: PHP puro ou com APC, eAccelerator ou FPM? Recomendo ativar um deles... vai fazer cache de compilaçao do php.. grandes ganhos. nginx é imprescindivel.. incrivel estar funcionando no linux atual.. mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no apache.. ja evitei de migrar uns tb. legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar mod_security... em algo q ja ta rodando. proximo passo, manda um netstat -m com seu ambiente tunado pra vermos como está, pra ver se da pra identificar ONDE está faltando tunar. Opa Fabricio, PHP com memcache. Pois é sempre fiquei indignado do site rodar bem e rápido em um Debian com kernel generic e não conseguir rodá-lo em um FreeBSD. :( [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 16:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 15:40, Rafael Henrique Faria wrote: Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. Boa tarde Rafael, Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo fazer essa migração, será meu próximo passo. O ambiente hoje é em php. []'s 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim Gondim, O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue, mas como foi mantido o antigo para efeitos de compatibilidade não faz diferença pratica. Esse knob seta apenas o limite máximo do kernel, a aplicação é
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 17:06, Fabricio Lima wrote: consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra nos? enquanto o DNS está virando gradualmente na internet, o site chega a abrir? e so depois q 'frita' q passa a nao abrir mais? quanto tem de memoria? Vou fazer um teste mais tarde. O teste é instantâneo porque uso a cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com os DNS. :) Altero o IP e aí é só contar até 10 rsrsrsrs Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui? []'s [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 17:04, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 16:48, Fabricio Lima wrote: PHP puro ou com APC, eAccelerator ou FPM? Recomendo ativar um deles... vai fazer cache de compilaçao do php.. grandes ganhos. nginx é imprescindivel.. incrivel estar funcionando no linux atual.. mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no apache.. ja evitei de migrar uns tb. legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar mod_security... em algo q ja ta rodando. proximo passo, manda um netstat -m com seu ambiente tunado pra vermos como está, pra ver se da pra identificar ONDE está faltando tunar. Opa Fabricio, PHP com memcache. Pois é sempre fiquei indignado do site rodar bem e rápido em um Debian com kernel generic e não conseguir rodá-lo em um FreeBSD. :( [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 12 de maio de 2015 16:16, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 15:40, Rafael Henrique Faria wrote: Boa tarde Gondim, quais problemas você teve com o nginx? O sistema é em PHP, ou alguma outra linguagem do tipo? Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar de 6k req/s sem dar muita carga no servidor. O nginx é um pouco chato de se configurar, principalmente por ele ter muito mais opções para melhorar a performance, mas no final o resultado é excelente. Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga muito alta, com o nginx, usando php-fpm, você consegue uma grande quantidade de req/s. Boa tarde Rafael, Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo fazer essa migração, será meu próximo passo. O ambiente hoje é em php. []'s 2015-05-12 15:31 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 14:34, Luiz Otavio O Souza wrote: 2015-05-12 11:56 GMT-03:00 Marcelo Gondim: On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Em 12/05/2015, à(s) 17:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 17:06, Fabricio Lima wrote: consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra nos? enquanto o DNS está virando gradualmente na internet, o site chega a abrir? e so depois q 'frita' q passa a nao abrir mais? quanto tem de memoria? Vou fazer um teste mais tarde. O teste é instantâneo porque uso a cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com os DNS. :) Altero o IP e aí é só contar até 10 rsrsrsrs Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui? []'s Pega o netstat -LnAa | grep f800079cb800 sendo o f800079cb800 a saída do sonewconn, você vai conseguir pegar se é o apache mesmo que está fazendo a fila. Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings do FreeBSD pra rodar com ele, neste link[1] . [1] http://nginx.org/en/docs/freebsd_tuning.html -- www.bsdjf.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] Problema estranho com sessão ssh e parece ser buffer
Caro Marcelo 2015-05-11 17:57 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: Pessoal, Queria saber se alguém aqui nessa lista já passou por isso e conseguiu resolver. O cenário é esse aqui: Estação (Rede escritório) Proxy FreeBSD - Firewall FreeBSD Provedor - router FreeBSD (Internet) Nessa situação acima eu faço um ssh para o router e rodo alguns programas como o top por exemplo. Funciona normal por um tempo. Depois de um tempo quando faço top o percentual não aparece, preciso ficar dando enter pra que o percentual fique atualizando. O ping não mostra mais pingando, tenho que ficar dando enter para ficar aparecendo os pings na tela. As vezes trava também o ssh seguido de um broken pipe. Isso só acontece de dentro aqui da rede local do escritório. Se eu conecto via PPPoE como um assinante de casa ou acesso de casa esse problema não ocorre. Parece que ocorre alguma coisa com buffer. Alguém já passou por isso? Estou pesquisando aqui ainda e se eu descobrir mando aqui a solução. Abrs. Eu não tenho ideia de qual é a causa deste problema mas, não sei o porquê, nas atualizações do FreeBSD-10.1-STABLE, o openssh6.6p1 é sermpre reinstalado por default. Como ele é uma versão não tão atualizada assim, eu instalo o openssh6.8p1 (baixado da página do openssh.com/openBSD). Talvez uma atualização do ssh possa resolver o caso. Fica a sugestão. Um abraço Edu - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Eduardo Lemos de Sa Associated Professor Level 4 Dep. Quimica da Universidade Federal do Paraná fone: +55(41)3361-3300 fax: +55(41)3361-3186 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 18:17, Tiago Ribeiro wrote: Em 12/05/2015, à(s) 17:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 12-05-2015 17:06, Fabricio Lima wrote: consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra nos? enquanto o DNS está virando gradualmente na internet, o site chega a abrir? e so depois q 'frita' q passa a nao abrir mais? quanto tem de memoria? Vou fazer um teste mais tarde. O teste é instantâneo porque uso a cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com os DNS. :) Altero o IP e aí é só contar até 10 rsrsrsrs Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui? []'s Pega o netstat -LnAa | grep f800079cb800 sendo o f800079cb800 a saída do sonewconn, você vai conseguir pegar se é o apache mesmo que está fazendo a fila. Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings do FreeBSD pra rodar com ele, neste link[1] . [1] http://nginx.org/en/docs/freebsd_tuning.html Fiz um teste agora e o resultado aí abaixo: # netstat -m 90991/8954/99945 mbufs in use (current/cache/total) 90990/1376/92366/1013816 mbuf clusters in use (current/cache/total/max) 90990/1355 mbuf+clusters out of packet secondary zone in use (current/cache) 0/300/300/506907 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/150194 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84484 16k jumbo clusters in use (current/cache/total/max) 204727K/6190K/210918K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 140 requests for I/O initiated by sendfile May 12 19:39:28 www kernel: sonewconn: pcb 0xf80229096930: Listen queue overflow: 30001 already in queue awaiting acceptance (20368 occurrences) Pois é não aparece esse endereçamento sonewconn saca só abaixo: # netstat -LnAa Current listen queue sizes (qlen/incqlen/maxqlen) TcpcbProto Listen Local Address f804401e6800 tcp4 33/0/5 186.193.48.14.443 f802a0d05400 tcp4 20358/2/5 186.193.48.14.80 f8000de95800 tcp4 0/0/128*.4321 f8000de95c00 tcp6 0/0/128*.4321 f8000dd74000 tcp4 0/0/150127.0.0.1.3306 Some tcp sockets may have been created. unix 0/0/150/tmp/mysql.sock unix 0/0/1024 /var/run/memcached.sock unix 0/0/4 /var/run/devd.pipe unix 0/0/4 /var/run/devd.seqpacket.pipe - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Tentou utilizar o varnish? Att Em 12 de maio de 2015 08:54, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: May 11 22:00:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (14881 occurrences) May 11 22:01:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (51121 occurrences) May 11 22:02:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (58249 occurrences) May 11 22:03:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (60405 occurrences) May 11 22:04:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (36380 occurrences) May 11 22:05:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (19147 occurrences) May 11 22:06:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (58622 occurrences) May 11 22:07:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (52858 occurrences) May 11 22:08:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (54807 occurrences) May 11 22:09:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (61702 occurrences) May 11 22:10:18 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (57843 occurrences) May 11 22:11:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (64611 occurrences) May 11 22:12:34 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (60650 occurrences) May 11 22:13:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (25439 occurrences) May 11 22:14:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (44406 occurrences) May 11 22:15:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (66628 occurrences) May 11 22:16:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (77971 occurrences) May 11 22:17:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (85202 occurrences) May 11 22:18:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (84189 occurrences) May 11 22:19:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (90504 occurrences) May 11 22:20:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (100342 occurrences) May 11 22:21:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (101364 occurrences) May 11 22:22:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (100651 occurrences) May 11 22:23:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (86571 occurrences) May 11 22:24:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (88348 occurrences) May 11 22:25:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (96432 occurrences) May 11 22:26:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (96487 occurrences) May 11 22:27:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (99970 occurrences) May 11 22:28:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (105325 occurrences) May 11 22:29:38 www
[FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: May 11 22:00:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (14881 occurrences) May 11 22:01:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (51121 occurrences) May 11 22:02:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (58249 occurrences) May 11 22:03:17 www kernel: sonewconn: pcb 0xf80060635188: Listen queue overflow: 767 already in queue awaiting acceptance (60405 occurrences) May 11 22:04:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (36380 occurrences) May 11 22:05:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (19147 occurrences) May 11 22:06:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (58622 occurrences) May 11 22:07:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (52858 occurrences) May 11 22:08:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (54807 occurrences) May 11 22:09:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (61702 occurrences) May 11 22:10:18 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (57843 occurrences) May 11 22:11:19 www kernel: sonewconn: pcb 0xf80377f61c40: Listen queue overflow: 767 already in queue awaiting acceptance (64611 occurrences) May 11 22:12:34 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (60650 occurrences) May 11 22:13:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (25439 occurrences) May 11 22:14:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (44406 occurrences) May 11 22:15:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (66628 occurrences) May 11 22:16:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (77971 occurrences) May 11 22:17:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (85202 occurrences) May 11 22:18:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (84189 occurrences) May 11 22:19:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (90504 occurrences) May 11 22:20:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (100342 occurrences) May 11 22:21:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (101364 occurrences) May 11 22:22:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (100651 occurrences) May 11 22:23:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (86571 occurrences) May 11 22:24:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (88348 occurrences) May 11 22:25:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (96432 occurrences) May 11 22:26:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (96487 occurrences) May 11 22:27:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (99970 occurrences) May 11 22:28:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (105325 occurrences) May 11 22:29:38 www kernel: sonewconn: pcb 0xf80089033498: Listen queue overflow: 767 already in queue awaiting acceptance (92724 occurrences) May 11 22:30:38
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Em Tue, 12 May 2015 09:59:56 -0300, Nilton Jose Rizzo escreveu Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm Já viu este site? https://rerepi.wordpress.com/2008/04/19/tuning-freebsd-sysoev-rit/ --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema estranho com sessão ssh e parece ser buffer
Enviado do meu smartphone Sony Xperia™ Eduardo Lemos de Sa escreveu Caro Marcelo 2015-05-11 17:57 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: Pessoal, Queria saber se alguém aqui nessa lista já passou por isso e conseguiu resolver. O cenário é esse aqui: Estação (Rede escritório) Proxy FreeBSD - Firewall FreeBSD Provedor - router FreeBSD (Internet) Nessa situação acima eu faço um ssh para o router e rodo alguns programas como o top por exemplo. Funciona normal por um tempo. Depois de um tempo quando faço top o percentual não aparece, preciso ficar dando enter pra que o percentual fique atualizando. O ping não mostra mais pingando, tenho que ficar dando enter para ficar aparecendo os pings na tela. As vezes trava também o ssh seguido de um broken pipe. Isso só acontece de dentro aqui da rede local do escritório. Se eu conecto via PPPoE como um assinante de casa ou acesso de casa esse problema não ocorre. Parece que ocorre alguma coisa com buffer. Alguém já passou por isso? Estou pesquisando aqui ainda e se eu descobrir mando aqui a solução. Abrs. Eu não tenho ideia de qual é a causa deste problema mas, não sei o porquê, nas atualizações do FreeBSD-10.1-STABLE, o openssh6.6p1 é sermpre reinstalado por default. Como ele é uma versão não tão atualizada assim, eu instalo o openssh6.8p1 (baixado da página do openssh.com/openBSD). Talvez uma atualização do ssh possa resolver o caso. Fica a sugestão. Um abraço Edu Pode ser burst no meio do caminho que usa a partir da rede que apresenta problemas. Fecha uma vpn e faz o teste. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Eduardo Lemos de Sa Associated Professor Level 4 Dep. Quimica da Universidade Federal do Paraná fone: +55(41)3361-3300 fax: +55(41)3361-3186 - 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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 10:43, Matheus L. Abreu wrote: O apache tem um lance de usar um modulo no kernel para aliviar a carga no userland. Tá usando isso? Dá uma diferença boa .. http://www.freebsd.org/cgi/man.cgi?query=accf_http To sim :) accf_data_load=YES accf_http_load=YES accf_dns_load=YES 2015-05-12 10:38 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 09:59, Nilton Jose Rizzo wrote: Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm E ae Rizzo :) Então, eu to querendo mexer o menos possível no ambiente onde roda o site pra evitar que surjam novos problemas. To pesquisando aqui enquanto isso. Tenho certeza que é tunning em algo. Procurei usar as mesmas configurações de apache, php e mysql que hoje já rodam no Debian. Acredito que o Linux lide melhor com essa situação específica devido à algum tunning automático dele. - 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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? -- Ricardo Campos Passanezi - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 10:01, Nilton Jose Rizzo wrote: Em Tue, 12 May 2015 09:59:56 -0300, Nilton Jose Rizzo escreveu Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm Já viu este site? https://rerepi.wordpress.com/2008/04/19/tuning-freebsd-sysoev-rit/ Opa Rizzo, Vi sim e me baseei nele saca só: # sysctl kern.ipc.nmbclusters kern.ipc.nmbclusters: 1013816 # sysctl net.inet.tcp.syncache.hashsize net.inet.tcp.syncache.hashsize: 32768 Esse aqui estava menor que no artigo: net.inet.tcp.syncache.bucketlimit=32 Aumentei para 100 agora # sysctl sysctl net.inet.tcp.syncookies net.inet.tcp.syncookies: 1 # sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 4096 # sysctl kern.ipc.maxsockets kern.ipc.maxsockets: 521725 # sysctl net.inet.tcp.tcbhashsize net.inet.tcp.tcbhashsize: 524288 # sysctl kern.maxfiles kern.maxfiles: 521721 # sysctl kern.maxfilesperproc kern.maxfilesperproc: 469548 # sysctl net.inet.tcp.recvspace net.inet.tcp.recvspace: 131072 # sysctl net.inet.tcp.sendspace net.inet.tcp.sendspace: 32768 # sysctl net.inet.tcp.msl net.inet.tcp.msl: 5000 # sysctl net.inet.ip.portrange.first net.inet.ip.portrange.first: 1024 Esse aqui tava diferente: net.inet.ip.portrange.randomized alterei para 0 agora. # sysctl net.inet.ip.portrange.last net.inet.ip.portrange.last: 65535 # sysctl net.inet.tcp.nolocaltimewait net.inet.tcp.nolocaltimewait: 0 # netstat -s -p tcp tcp: 18286064 packets sent 1902552 data packets (1327754573 bytes) 57073 data packets (30751964 bytes) retransmitted 1041 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 14505610 ack-only packets (223388 delayed) 0 URG only packets 0 window probe packets 19158 window update packets 1801671 control packets 25623791 packets received 4280347 acks (for 1076817911 bytes) 1180963 duplicate acks 8784003 acks for unsent data 2533587 packets (914392400 bytes) received in-sequence 45386 completely duplicate packets (9556216 bytes) 0 old duplicate packets 122 packets with some dup. data (75716 bytes duped) 8450 out-of-order packets (7620267 bytes) 24296 packets (0 bytes) of data after window 0 window probes 3993 window update packets 11520 packets received after close 4 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 607007 connection requests 1148091 connection accepts 0 bad connection attempts 4656475 listen queue overflows 146080 ignored RSTs in the windows 1702936 connections established (including accepts) 1770589 connections closed (including 543865 drops) 33048 connections updated cached RTT on close 33049 connections updated cached RTT variance on close 23573 connections updated cached ssthresh on close 5698 embryonic connections dropped 3043526 segments updated rtt (of 3246858 attempts) 190313 retransmit timeouts 3790 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 42758 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 125964 correct ACK header predictions 1362285 correct data packet header predictions 3539932 syncache entries added 933 retransmitted 8722 dupsyn 0 dropped 1148091 completed 0 bucket overflow 0 cache overflow 3080 reset 100 stale 4656491 aborted 0 badack 11 unreach 0 zone failures 3539932 cookies sent 2267854 cookies received 536 hostcache entries added 0 bucket overflow 580 SACK
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisiçã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] Problema estranho com sessão ssh e parece ser buffer
On 12-05-2015 08:01, Eduardo Lemos de Sa wrote: Caro Marcelo 2015-05-11 17:57 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: Pessoal, Queria saber se alguém aqui nessa lista já passou por isso e conseguiu resolver. O cenário é esse aqui: Estação (Rede escritório) Proxy FreeBSD - Firewall FreeBSD Provedor - router FreeBSD (Internet) Nessa situação acima eu faço um ssh para o router e rodo alguns programas como o top por exemplo. Funciona normal por um tempo. Depois de um tempo quando faço top o percentual não aparece, preciso ficar dando enter pra que o percentual fique atualizando. O ping não mostra mais pingando, tenho que ficar dando enter para ficar aparecendo os pings na tela. As vezes trava também o ssh seguido de um broken pipe. Isso só acontece de dentro aqui da rede local do escritório. Se eu conecto via PPPoE como um assinante de casa ou acesso de casa esse problema não ocorre. Parece que ocorre alguma coisa com buffer. Alguém já passou por isso? Estou pesquisando aqui ainda e se eu descobrir mando aqui a solução. Abrs. Eu não tenho ideia de qual é a causa deste problema mas, não sei o porquê, nas atualizações do FreeBSD-10.1-STABLE, o openssh6.6p1 é sermpre reinstalado por default. Como ele é uma versão não tão atualizada assim, eu instalo o openssh6.8p1 (baixado da página do openssh.com/openBSD). Talvez uma atualização do ssh possa resolver o caso. Fica a sugestão. Um abraço Edu Valeu Eduardo, vou ver aqui. O estranho é porque isso só acontece com acessos de dentro daqui da rede local e quando acesso de casa o problema não acontece. Vou fazer um teste aqui :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Palestra do 1º BSD Day
Podemos improvisar algo, como uma demonstração de sysctl, dizendo a sintaxe e algumas das opções de configuração de sistema. Isto pode ser feito por mais de uma pessoa, cada um mostrando coisas que usa no dia a dia. João Rocha. -- http://jgoffredo.blogspot.com Enviado do tablet. Qualquer fotografia/imagem que tenha sido enviada anexada neste e-mail não implica em autorização de o uso comercial, exceto se mencionado em contrário no corpo do e-mail. Em 12/05/2015 10:58, Nilton Jose Rizzo ri...@i805.com.br escreveu: Galera, recebi uma noticia ruim, um dos palestrantes ( André ) esta com dengue, e não vai poder comparecer ao evento no sábado agora. Alguem gostaria de palestrar em seu lugar? --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ - 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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
O apache tem um lance de usar um modulo no kernel para aliviar a carga no userland. Tá usando isso? Dá uma diferença boa .. http://www.freebsd.org/cgi/man.cgi?query=accf_http 2015-05-12 10:38 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 12-05-2015 09:59, Nilton Jose Rizzo wrote: Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm E ae Rizzo :) Então, eu to querendo mexer o menos possível no ambiente onde roda o site pra evitar que surjam novos problemas. To pesquisando aqui enquanto isso. Tenho certeza que é tunning em algo. Procurei usar as mesmas configurações de apache, php e mysql que hoje já rodam no Debian. Acredito que o Linux lide melhor com essa situação específica devido à algum tunning automático dele. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- *Matheus Lamberti de Abreu* - Para obter algo que você nunca teve, precisa fazer algo que nunca fez. - Not all those who wander are lost. (J.R.R. Tolkien) - If you can't explain it simply, you don't understand it well enough. (Albert Einstein) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Palestra do 1º BSD Day
Galera, recebi uma noticia ruim, um dos palestrantes ( André ) esta com dengue, e não vai poder comparecer ao evento no sábado agora. Alguem gostaria de palestrar em seu lugar? --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 09:59, Nilton Jose Rizzo wrote: Em Tue, 12 May 2015 08:54:27 -0300, Marcelo Gondim escreveu Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: Godim, poe o -current e testa, otimiza o kernel antes tenta rodar com apache 2.4 tbm E ae Rizzo :) Então, eu to querendo mexer o menos possível no ambiente onde roda o site pra evitar que surjam novos problemas. To pesquisando aqui enquanto isso. Tenho certeza que é tunning em algo. Procurei usar as mesmas configurações de apache, php e mysql que hoje já rodam no Debian. Acredito que o Linux lide melhor com essa situação específica devido à algum tunning automático dele. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 12-05-2015 11:24, Marcelo Gondim wrote: On 12-05-2015 11:07, Ricardo Campos Passanezi wrote: On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote: Bom dia à todos, HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que na época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable. Hoje ele roda em cima de Debian e estou novamente com um ambiente aqui para tentar fazer essa bagaça rodar no FreeBSD. :) O problema pelo visto são as milhares de requisições por segundo que é feito pelo tracker. Site começa à entrar e então despenca. O load quando inicio o apache vai à uns 400 e depois vai caindo e a única coisa que vejo bastante nos logs é isso: ... Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem uma ideia sobre isso acima? Estou catando aqui Google alguma esperança. Porque dia 20 mudaremos de Datacenter e se até lá não conseguir fazer isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O Freeba é esse aqui: FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r281836: Wed Apr 29 12:21:07 BRT 2015 r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64 Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx? Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual é com apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo. Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje funciona com apache 2.2 e não tenho problemas. Mas pode ser outra tentativa embora acredite que seja algum tunning do sistema que esteja faltando pra essa quantidade toda de requisição. Achei essa thread [1] aqui na lista mas também não houve uma solução do problema. [1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao Jorge o que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou. Soda rsrsrsrsr []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
