Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Possivelmente vc já fez isso e tbm não tenho certeza se é o caminho para resolver o seu problema. Já tentou fazer customização de performance pelos parâmetros do sysctl.conf? Faço uns mais voltados para melhora do desempenho de rede q realmente dão um ganho muito significativo. Muito legal saber q o manicômio, que sou usuário, estará em breve rodando em um FreeBSD, isso me anima até em ser vip. . Se o Marcelo fizer uma promoção, diminuir a necessidade de pontos necessários para convites, eu até posso distribuir alguns, pq tenho alguns pontos sobrando. 2015-06-09 20:40 GMT-03:00 Giovanni Tirloni g...@gtirloni.com: Marcelo, Sua fila de conexoes estao enchendo porque a $aplicacao nao esta dando accept() rapido o suficiente. Provavelmente ela tambem esta sendo limitada por alguma outra coisa. Nao adianta aumentar o somaxconn, isso so' vai retardar o problema. Voce precisa investigar _onde_ que a $aplicacao esta gastando tempo. Por favor poste em algum lugar sua configuracao do MariaDB, Apache e memcached em algum lugar que possamos verificar (ex. pastebin.com). O ideal e' simular esse workload artificialmente em um servidor de testes para fazer o problema acontecer. Se nao for possivel ou viavel nesse momento, e voce puder apontar o trafego de producao por algum tempo ate' comecar a dar problema, seria interessante a saida do dos comandos: netstat -an -f inet netstat.txt lsof -i lsof_i.txt lsof lsof.txt top -d 10 -s 1 -n top.txt Coloque isso em algum lugar que possamos olhar e vai ser mais facil te ajudar :) Giovanni - 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 09/06/2015 10:59, Marcelo Gondim wrote: On 07-06-2015 15:43, Nilton Jose Rizzo wrote: Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? Olha este link aqui http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server Opa Rizzo, Esse mesmo que eu peguei :) Então. Eu tive que migrar pro Datacenter novo usando o Debian mesmo. Mas não desisti ainda. Vou pegar um Dell R720 aqui, colocar uns 32Gb de ram nele e aí é muito simples de fazer os testes porque usamos a CloudFlare. Só entro lá e mudo o IP de destino e é instantâneo pra fazer o teste. :) Assim que acertar isso aqui eu posto os resultados. já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Estou interessado nos resultados tb. Vai nos informando dos seus testes. Podia sortear uns convites do manicomio-share pra galera. hehehe Abs, Willien - 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 09-06-2015 15:48, Herberson Miranda wrote: Uma dúvida como você está monitorando a performance do servidor? basicamente load do sistema e i/o de disco. O i/o é baixíssimo ainda mais porque está rodando embaixo de uma controladora Raid 10. O hardware é esse abaixo: 1U 5017R-MTF Xeon E5 4bay Intel 6core E5-2620V2 2.1Ghz 80W 4 x Kingston 16GB DDR3 1600Mhz ECC REG Onboard IPMI/KVM with Dedicated LAN Without DVD player 350W Gold Level Power Supply 4 x Seagate SAS ST3300657SS 300GB 15K LSI MegaRAID SAS 9260-4i 6Gb/s RAID-10 Network: 1Gigabit Uplink 10TB Traffic 2IPv4 On 09-06-2015 15:15, Marcelo Gondim wrote: Opa Matheus, On 08-06-2015 20:34, Matheus Weber da Conceição wrote: Gondim, já tentou setar o limite máximo de memória na conf do mysql/mariadb? Limite máximo? Esse não vi não. A configuração atual consome uns 26Gb. Usei esse link aqui [1] pra cálculo. [1] http://www.mysqlcalculator.com/ -Matheus 2015-06-07 22:00 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 07-06-2015 02:07, Nilton Jose Rizzo wrote: Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Boa ideia Rizzo, Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por esse parâmetro. 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
Opa Matheus, On 08-06-2015 20:34, Matheus Weber da Conceição wrote: Gondim, já tentou setar o limite máximo de memória na conf do mysql/mariadb? Limite máximo? Esse não vi não. A configuração atual consome uns 26Gb. Usei esse link aqui [1] pra cálculo. [1] http://www.mysqlcalculator.com/ -Matheus 2015-06-07 22:00 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 07-06-2015 02:07, Nilton Jose Rizzo wrote: Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Boa ideia Rizzo, Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por esse parâmetro. 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 09-06-2015 11:23, Willien BSD wrote: On 09/06/2015 10:59, Marcelo Gondim wrote: On 07-06-2015 15:43, Nilton Jose Rizzo wrote: Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? Olha este link aqui http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server Opa Rizzo, Esse mesmo que eu peguei :) Então. Eu tive que migrar pro Datacenter novo usando o Debian mesmo. Mas não desisti ainda. Vou pegar um Dell R720 aqui, colocar uns 32Gb de ram nele e aí é muito simples de fazer os testes porque usamos a CloudFlare. Só entro lá e mudo o IP de destino e é instantâneo pra fazer o teste. :) Assim que acertar isso aqui eu posto os resultados. já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Estou interessado nos resultados tb. Vai nos informando dos seus testes. Podia sortear uns convites do manicomio-share pra galera. hehehe Abs, ahahahah se eu conseguir fazer isso vou sortear mesmo :) Assim que tiver mais resultados posto aqui. []'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
Uma dúvida como você está monitorando a performance do servidor? On 09-06-2015 15:15, Marcelo Gondim wrote: Opa Matheus, On 08-06-2015 20:34, Matheus Weber da Conceição wrote: Gondim, já tentou setar o limite máximo de memória na conf do mysql/mariadb? Limite máximo? Esse não vi não. A configuração atual consome uns 26Gb. Usei esse link aqui [1] pra cálculo. [1] http://www.mysqlcalculator.com/ -Matheus 2015-06-07 22:00 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 07-06-2015 02:07, Nilton Jose Rizzo wrote: Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Boa ideia Rizzo, Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por esse parâmetro. Valeu! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Att, Herberson S. Miranda Twitter: @__von Website: http://0fx66.com/ OpenPGP: 0xBAF28DE1 []'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
Em 9 de junho de 2015 16:10, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 09-06-2015 15:48, Herberson Miranda wrote: Uma dúvida como você está monitorando a performance do servidor? basicamente load do sistema e i/o de disco. O i/o é baixíssimo ainda mais porque está rodando embaixo de uma controladora Raid 10. O hardware é esse abaixo: 1U 5017R-MTF Xeon E5 4bay Intel 6core E5-2620V2 2.1Ghz 80W 4 x Kingston 16GB DDR3 1600Mhz ECC REG Onboard IPMI/KVM with Dedicated LAN Without DVD player 350W Gold Level Power Supply 4 x Seagate SAS ST3300657SS 300GB 15K LSI MegaRAID SAS 9260-4i 6Gb/s RAID-10 Tu consegue mexer nesse hardware? Tenta adicionar um ou mais SSDs e troca o storage para ZFS, fazendo a parte de cache nos SSDs. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Marcelo, Sua fila de conexoes estao enchendo porque a $aplicacao nao esta dando accept() rapido o suficiente. Provavelmente ela tambem esta sendo limitada por alguma outra coisa. Nao adianta aumentar o somaxconn, isso so' vai retardar o problema. Voce precisa investigar _onde_ que a $aplicacao esta gastando tempo. Por favor poste em algum lugar sua configuracao do MariaDB, Apache e memcached em algum lugar que possamos verificar (ex. pastebin.com). O ideal e' simular esse workload artificialmente em um servidor de testes para fazer o problema acontecer. Se nao for possivel ou viavel nesse momento, e voce puder apontar o trafego de producao por algum tempo ate' comecar a dar problema, seria interessante a saida do dos comandos: netstat -an -f inet netstat.txt lsof -i lsof_i.txt lsof lsof.txt top -d 10 -s 1 -n top.txt Coloque isso em algum lugar que possamos olhar e vai ser mais facil te ajudar :) Giovanni - 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 07-06-2015 15:43, Nilton Jose Rizzo wrote: Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? Olha este link aqui http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server Opa Rizzo, Esse mesmo que eu peguei :) Então. Eu tive que migrar pro Datacenter novo usando o Debian mesmo. Mas não desisti ainda. Vou pegar um Dell R720 aqui, colocar uns 32Gb de ram nele e aí é muito simples de fazer os testes porque usamos a CloudFlare. Só entro lá e mudo o IP de destino e é instantâneo pra fazer o teste. :) Assim que acertar isso aqui eu posto os resultados. já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? - 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
Gondim, já tentou setar o limite máximo de memória na conf do mysql/mariadb? -Matheus 2015-06-07 22:00 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 07-06-2015 02:07, Nilton Jose Rizzo wrote: Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Boa ideia Rizzo, Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por esse parâmetro. Valeu! - 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
Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? Olha este link aqui http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? - 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 --- /* **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 07-06-2015 02:07, Nilton Jose Rizzo wrote: Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? Boa ideia Rizzo, Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por esse parâmetro. 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 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. - 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 Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu On 05-06-2015 18:26, Nilton Jose Rizzo wrote: Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM Grande Rizzo, Nada hehe mas o que pega e o que pegou no passado está relacionado ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta performance que o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 800% rsrsrsrs A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá aguentando a enxurrada ahahahaha Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian. Pelo que percebi não é o Apache o limitador mas o mysql. Já experimentou trocar o banco? por ou o posgre ou o maria-db? Talvés possa ter uma gerencia melhor dos recuros ou ver um tunning mais afiado para o mysql ... sei lá ... Agora que me veio uma ideia na cuca ... tem uma variável no mysql que é o time out da conexão, que ele fecha quando percebe que a conexão ficou aberta sem um fechamento explícito coisas que programadores de php geralmente fazem ... ai fica as conexões abertas e sócaem com o timeout X. Dá uma olhada nisso e me diz, ok? - 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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Gondim, E ai já portou tudo para o FreeBSD? já viu este link? https://wiki.apache.org/httpd/PHP-FPM --- /* **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
2015-05-13 22:05 GMT-03:00 Marcelo Gondim gon...@bsdinfo.com.br: On 13-05-2015 15:36, Rafael Henrique Faria wrote: Verdade, bem lembrado pelo Nilton. Durante a utilização do servidor, fique acompanhando o iostat -x 1 Veja a porcentagem de uso do disco (ultima coluna). Se estiver travado em 100%, o gargalo pode estar aí. Opa boa vou checar isso também. O servidor de teste tem um SSD de 250Gb EVO da Samsung. Vou olhar isso. Eu não sei como pode estar funcionando esse seu sistema. Mas como é um tracker privado, imagino que ele deve fazer os seguintes procedimentos: - ele recebe a requisição informando um hash do torrent, e também um hash do passkey. Com isso o programa precisará realizar 2 consultas ao banco de dados, uma para verificar o hash do torrent, e obter as informações do mesmo, e a segunda consulta para verificar o acesso da passkey. - em seguida será atualizada a quantidade de bytes enviados e recebidos por aquele passkey (daquele usuário em questão), para contabilização. Será um update em alguma tabela do banco. - e ele pode também estar fazendo uma verificação de quantas pessoas estão realizando o seeding e o leeching deste torrent, assim atualizando outra tabela. Em média serão 2 acessos de leitura ao banco, e 2 acessos de gravação. Isso para cada requisição. O mariadb está no mesmo servidor? Quantas conexões ele está configurado para receber? Lembre de manter sempre em sincronia a quantidade de threads que o apache possui com a quantidade de conexões que o seu banco pode receber. O mariadb está no mesmo servidor. Eu usei uma vez aqueles programas pra optimizar o acesso à base. Depois vou colar aqui o my.cnf que agora to sem acesso ao servidor de testes. Essa é uma das vantagens de se utilizar o php-fpm, você consegue manipular melhor essa relação de instâncias do servidor de aplicação X conexões ao banco de dados. Você chegou a monitorar a quantidade de queries que o mariadb está recebendo no momento que o servidor não aguenta mais? Qual o tempo de processamento de cada uma destas aplicações (mariadb e apache)? Boa sorte aí. Abraço. 2015-05-13 15:06 GMT-03:00 Nilton Jose Rizzo ri...@i805.com.br: Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu 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
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
Blz Ta mole Aumenta mbufs e bytes allocated to network To no cel Em terça-feira, 12 de maio de 2015, Marcelo Gondim gon...@bsdinfo.com.br escreveu: 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 -- [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. - 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
Vc informou anteriormente: # sysctl kern.ipc.nmbclusters kern.ipc.nmbclusters: 1013816 Cada cluster consome 2K de memoria. como vc ja ta com 1milhao de mbufs. o q daria 2GB ram. Como essa maquina é amd64, vamos aumentar isso. ___dobra este valor.__ poe 2048000 Esse servidor precisa ter no minimo 8gb. serao 4gb so pra entregar as conexoes pro apache! e uns 4gb pra banco/apache. altera tb os pontos abaixo, achei seus valores muito 'fraquinhos' e outros tunaram pro proprio valor default: kern.ipc.maxsockbuf=4194304 #este é o valor indicado pra gigabit, mesmo q vc esteja em 100mbit, creio q vc ta topando esta placa, o q lhe deixaria elegivel pra usar este valor. net.inet.tcp.sendbuf_max=4194304 # (default 2097152) net.inet.tcp.recvbuf_max=4194304 # (default 2097152) kern.ipc.soacceptqueue=1024 # backlog queue depth for accepting new TCP connections net.inet.tcp.mssdflt=1460 # maximum segment size (largest payload) net.inet.tcp.recvspace: 262144 # estava em 128k net.inet.tcp.sendspace: 262144 # estava no default 32k agora quero ver esse cabrunco nao aguentar... mesmo eskema, aplica estes valores, vira o IP, e na hora q der crash pega o nestat -m e aquele outro q sugeriram q tem tanta letra q nao consigo decorar heheeh -Lapnmasdfhasdflasd [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 13 de maio de 2015 05:44, Fabricio Lima lis...@fabriciolima.com.br escreveu: Blz Ta mole Aumenta mbufs e bytes allocated to network To no cel Em terça-feira, 12 de maio de 2015, Marcelo Gondim gon...@bsdinfo.com.br escreveu: 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 -- [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. - 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
Verdade, bem lembrado pelo Nilton. Durante a utilização do servidor, fique acompanhando o iostat -x 1 Veja a porcentagem de uso do disco (ultima coluna). Se estiver travado em 100%, o gargalo pode estar aí. Eu não sei como pode estar funcionando esse seu sistema. Mas como é um tracker privado, imagino que ele deve fazer os seguintes procedimentos: - ele recebe a requisição informando um hash do torrent, e também um hash do passkey. Com isso o programa precisará realizar 2 consultas ao banco de dados, uma para verificar o hash do torrent, e obter as informações do mesmo, e a segunda consulta para verificar o acesso da passkey. - em seguida será atualizada a quantidade de bytes enviados e recebidos por aquele passkey (daquele usuário em questão), para contabilização. Será um update em alguma tabela do banco. - e ele pode também estar fazendo uma verificação de quantas pessoas estão realizando o seeding e o leeching deste torrent, assim atualizando outra tabela. Em média serão 2 acessos de leitura ao banco, e 2 acessos de gravação. Isso para cada requisição. O mariadb está no mesmo servidor? Quantas conexões ele está configurado para receber? Lembre de manter sempre em sincronia a quantidade de threads que o apache possui com a quantidade de conexões que o seu banco pode receber. Essa é uma das vantagens de se utilizar o php-fpm, você consegue manipular melhor essa relação de instâncias do servidor de aplicação X conexões ao banco de dados. Você chegou a monitorar a quantidade de queries que o mariadb está recebendo no momento que o servidor não aguenta mais? Qual o tempo de processamento de cada uma destas aplicações (mariadb e apache)? Boa sorte aí. Abraço. 2015-05-13 15:06 GMT-03:00 Nilton Jose Rizzo ri...@i805.com.br: Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu 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 Godim essas requisições são para o apache, corretp? mas e se não for o apache o problema e sim o mysql? Já pensou que cada requisição precisa realizar uma query no banco, será que seu sistema de arquivos / disco não está suportando o mysql?
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 13-05-2015 11:12, Fabricio Lima wrote: Vc informou anteriormente: # sysctl kern.ipc.nmbclusters kern.ipc.nmbclusters: 1013816 Cada cluster consome 2K de memoria. como vc ja ta com 1milhao de mbufs. o q daria 2GB ram. Como essa maquina é amd64, vamos aumentar isso. ___dobra este valor.__ poe 2048000 Esse servidor precisa ter no minimo 8gb. serao 4gb so pra entregar as conexoes pro apache! e uns 4gb pra banco/apache. Então essa máquina de teste tem 16Gb de ram mas o servidor em produção tem 48Gb e usa quase toda ela. Quanto ao tráfego é muito pouco em torno de 5Mbps com cloudflare e 30Mbps sem cloudflare. O lance mesmo são a quantidade de conexões simultâneas que temos por causa do tracker. Olha a estatística: Informações de Usuários Online no Momento2461 Online nas Últimas 24 Horas24174 Último Membro Registradomarlomattos Registros Hoje30 Total de Registrados139,317 Pendentes0 Homens122,463 Mulheres14,799 Sexo Indefinido2,055 Advertidos1,027 Total Upado158.33 PB Informações de Torrents Total de Torrents174,151 Torrents Ativos88,273 Torrents reciclados 4,759 Torrents na Moderação3 Peers584,893 Seeders556,548 Leechers28,345 Conectáveis Sim251,581 Conectáveis Não333,253 Status de Registro Mensal MêsUsuarios 2015-05526 2015-041348 2015-031312 2015-021230 2015-011355 2014-121311 2014-111272 altera tb os pontos abaixo, achei seus valores muito 'fraquinhos' e outros tunaram pro proprio valor default: kern.ipc.maxsockbuf=4194304 #este é o valor indicado pra gigabit, mesmo q vc esteja em 100mbit, creio q vc ta topando esta placa, o q lhe deixaria elegivel pra usar este valor. net.inet.tcp.sendbuf_max=4194304 # (default 2097152) net.inet.tcp.recvbuf_max=4194304 # (default 2097152) kern.ipc.soacceptqueue=1024 # backlog queue depth for accepting new TCP connections net.inet.tcp.mssdflt=1460 # maximum segment size (largest payload) net.inet.tcp.recvspace: 262144 # estava em 128k net.inet.tcp.sendspace: 262144 # estava no default 32k agora quero ver esse cabrunco nao aguentar... Vou checar com essas confs valeu!!! :) mesmo eskema, aplica estes valores, vira o IP, e na hora q der crash pega o nestat -m e aquele outro q sugeriram q tem tanta letra q nao consigo decorar heheeh -Lapnmasdfhasdflasd [ ]'s Fabricio Lima Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrifice of a live chicken. Em 13 de maio de 2015 05:44, Fabricio Lima lis...@fabriciolima.com.br escreveu: Blz Ta mole Aumenta mbufs e bytes allocated to network To no cel Em terça-feira, 12 de maio de 2015, Marcelo Gondim gon...@bsdinfo.com.br escreveu: 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
Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa
On 13-05-2015 15:36, Rafael Henrique Faria wrote: Verdade, bem lembrado pelo Nilton. Durante a utilização do servidor, fique acompanhando o iostat -x 1 Veja a porcentagem de uso do disco (ultima coluna). Se estiver travado em 100%, o gargalo pode estar aí. Opa boa vou checar isso também. O servidor de teste tem um SSD de 250Gb EVO da Samsung. Vou olhar isso. Eu não sei como pode estar funcionando esse seu sistema. Mas como é um tracker privado, imagino que ele deve fazer os seguintes procedimentos: - ele recebe a requisição informando um hash do torrent, e também um hash do passkey. Com isso o programa precisará realizar 2 consultas ao banco de dados, uma para verificar o hash do torrent, e obter as informações do mesmo, e a segunda consulta para verificar o acesso da passkey. - em seguida será atualizada a quantidade de bytes enviados e recebidos por aquele passkey (daquele usuário em questão), para contabilização. Será um update em alguma tabela do banco. - e ele pode também estar fazendo uma verificação de quantas pessoas estão realizando o seeding e o leeching deste torrent, assim atualizando outra tabela. Em média serão 2 acessos de leitura ao banco, e 2 acessos de gravação. Isso para cada requisição. O mariadb está no mesmo servidor? Quantas conexões ele está configurado para receber? Lembre de manter sempre em sincronia a quantidade de threads que o apache possui com a quantidade de conexões que o seu banco pode receber. O mariadb está no mesmo servidor. Eu usei uma vez aqueles programas pra optimizar o acesso à base. Depois vou colar aqui o my.cnf que agora to sem acesso ao servidor de testes. Essa é uma das vantagens de se utilizar o php-fpm, você consegue manipular melhor essa relação de instâncias do servidor de aplicação X conexões ao banco de dados. Você chegou a monitorar a quantidade de queries que o mariadb está recebendo no momento que o servidor não aguenta mais? Qual o tempo de processamento de cada uma destas aplicações (mariadb e apache)? Boa sorte aí. Abraço. 2015-05-13 15:06 GMT-03:00 Nilton Jose Rizzo ri...@i805.com.br: Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu 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 19:47:03 -0300, Marcelo Gondim escreveu 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 Godim essas requisições são para o apache, corretp? mas e se não for o apache o problema e sim o mysql? Já pensou que cada requisição precisa realizar uma query no banco, será que seu sistema de arquivos / disco não está suportando o mysql? --- /* **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 13-05-2015 15:06, Nilton Jose Rizzo wrote: Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu 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 Godim essas requisições são para o apache, corretp? mas e se não for o apache o problema e sim o mysql? Já pensou que cada requisição precisa realizar uma query no banco, será que seu sistema de arquivos / disco não está suportando o mysql? Opa Rizzo, Então nos testes ontem, depois que enviei esse e-mail eu achei um parâmetro no apache que faltava configurar e depois disso tive a mensagem de falta de memória pro mysql. Acredito que agora seja isso e como não tenho como aumentar a memória aqui nesse meu server de teste, vou deixar para fazer os últimos testes no servidor que ficará em produção mesmo. Esse aqui: 1U 5017R-MTF Xeon E5 4bay Intel 6core E5-2620V2 2.1Ghz 80W 4 x Kingston 16GB DDR3 1600Mhz ECC REG Onboard IPMI/KVM with Dedicated LAN Without DVD player 350W Gold Level Power Supply 4 x Seagate SAS ST3300657SS 300GB 15K LSI MegaRAID SAS 9260-4i 6Gb/s Network: 1Gigabit Uplink 10TB Traffic 2IPv4 Acredito que esse irá suportar muito bem rsrsrsrs aí lá vai ser a vera. []'s 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] 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] 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
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] 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] 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
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
