Re: [pgbr-geral] Como resolver alta demanda de conexoes
*PARA OS DBAS jr* ou candidato há .. ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA , SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER . SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada aqui q Seja Livre! Use OpenSource! LineOn, Tecnologia da Informação! http://lineonti.wordpress.com Em 3 de fevereiro de 2014 11:54, Tiago Adami adam...@gmail.com escreveu: Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2014-02-03 Cicero Neto cicero@gmail.com: rever indices locais e orbitais Alguém já entendeu o que o Cícero quer dizer com isso? Estava redigindo uma pergunta à lista quando sua mensagem apareceu - ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um momento me senti emburrecido por não conhecer a diferença entre os dois... TIAGO J. ADAMI http://www.adamiworks.com @tiadami ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
que fico pasmo pas.mo *sm* (*lat spasmu*) *1* Assombro, espanto, grande admiração. *2* Desfalecimento, desmaio. *3 **Vet V tétano. **4 **Reg* (Sul e Centro) Contração espasmódica dos músculos maxilares, por excessiva sede da rês. *adj V pasmado*. Entenderam??? Seja Livre! Use OpenSource! LineOn, Tecnologia da Informação! http://lineonti.wordpress.com Em 5 de fevereiro de 2014 14:27, Cicero Neto cicero@gmail.comescreveu: *PARA OS DBAS jr* ou candidato há .. ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA , SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER . SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada aqui q Seja Livre! Use OpenSource! LineOn, Tecnologia da Informação! http://lineonti.wordpress.com Em 3 de fevereiro de 2014 11:54, Tiago Adami adam...@gmail.com escreveu: Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2014-02-03 Cicero Neto cicero@gmail.com: rever indices locais e orbitais Alguém já entendeu o que o Cícero quer dizer com isso? Estava redigindo uma pergunta à lista quando sua mensagem apareceu - ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um momento me senti emburrecido por não conhecer a diferença entre os dois... TIAGO J. ADAMI http://www.adamiworks.com @tiadami ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 5 de fevereiro de 2014 14:27, Cicero Neto cicero@gmail.comescreveu: *PARA OS DBAS jr* ou candidato há .. ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA , SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER . SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada aqui q Não vou debater sobre as tuas informações pra não gerar mais discussão. E nada contra, Cícero, e com todo o respeito do mundo, mas respeito e credibilidade não se conquistam impondo credenciais. Na minha opinião, quem precisa adicionar isso a qualquer informação, faz isso porque a própria informação não tem a acreditação ou argumentação necessária. Além disso, isso já fugiu do tópico. Desculpas por isso. []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
On 05-02-2014 13:27, Cicero Neto wrote: *PARA OS DBAS jr* ou candidato há .. s/há/a/ ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA , SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER . [não precisa gritar...] De qual literatura você tirou a nomenclatura índice orbital? Nos principais livros de banco de dados (Ramakrishnan, Ullman, Navathe, Silberschatz, para citar alguns) *não* há uso de tal termo. Nem mesmo uma busca no pai dos burros (google) retornou algo conclusivo. Portanto, não me admira a *grande* maioria desta lista não conhecer tal termo. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
2014-02-05 Cicero Neto cicero@gmail.com: PARA OS DBAS jr ou candidato há .. Para quem não respeita a netiqueta, maiúsculas são grito e não são bem vistas. Também é bom saber escrever português. Há candidados a DBA júnior, mas não se pode confundir o verbo haver (há) com a partícula ‘a’. ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA E o que seria indexação não física? Lógica? Espiritual? Indexação, em SGBDs, é um conceito exclusivamente físico. OU SEJA DIRETO NA TABELA, COMO UMA PK Chaves são conceitos lógicos, e índices físicos; mas os índices associados a chaves não diferem em nada de outros índices, nem mesmo se forem chaves primárias. Todo índice ou chave é obviamente ligado a uma tabela, mas é uma estrutura separada. ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA Isso não faz sentido. Nunca vi esse conceito em SGBD nenhum, muito menos na teoria. SÃO TABELAS DE ÍNDICES AUXILIARES Índices e tabelas não se confundem: não há nem ‘tabelas de índices’, nem ‘índices auxiliares’. Não que eu me lembre. COMO SE FOSSE O ÍNDICE DE UM LIVRO. Entendo um pouco de livros, e um pouco de SGBDs. Os dois têm em comum conterem informações, mas certamente não muito mais do que isso. Essa tua símile não carrega informação nenhuma. ISSO GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER . Falaste, falaste, e não disseste nada. SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. Ai de teus usuários. leio muita coisa postada aqui E, pelo jeito, não entendeste nada. Tenho que te pedir para não responder mais nenhuma pergunta técnica, por óbvia falta de capacidade de comunicação, provavelmente de conhecimento básico também. Embora a gente se preocupe em corrigir, isso desperdiça tempo de todos e, em especial, confunde os novatos. E o que dizes nem são os enganos comuns de novatos, que acabamos ensinando (e até aprendendo) algo, ao corrigir. Limite‐se a perguntar, por favor, até aprender mais. Uma dica: decorar regras para aplicar sem entender não é conhecimento, é decoreba. Essas regras impedem que a experiência gere conhecimento, abandone‐as e estude os conceitos básicos. Só depois volte a se preocupar com produtos e tecnologia. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Bom dia! Olha, me parece improvável você ter esse problema, para um banco de dados tão pequeno. Acredito que seja necessário fazer um tunning na base de dados, rever indices locais e orbitais, substituir consultas em tabelas por visões, rever procs, gatilhos, etc. Extraia planos de execução, veja se o acesso a base está correto. Sou DBA SR e sinceramente, acredito que Hardware não resolve ou mascara o problema. Att. Seja Livre! Use OpenSource! LineOn, Tecnologia da Informação! http://lineonti.wordpress.com Em 1 de fevereiro de 2014 03:42, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Fico feliz que tenha evoluído com seus resultados! Agora é hora de tirar o segundo truque da cartola do PgBouncer: crie mais um banco de dados virtual apontando pro mesmo banco real, e aponte sua aplicação web para esse banco separado. Assim, você terá uma fila exclusiva para a aplicação web, que certamente tem perfil diferente da outra, e você pode controlar quantas conexões vai reservar pra cada lado. Tente e conte pra nós. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
2014-02-03 Cicero Neto cicero@gmail.com: Acredito que seja necessário fazer um tunning na base de dados /Tuning/. rever indices locais e orbitais Alguém já entendeu o que o Cícero quer dizer com isso? Extraia planos de execução, veja se o acesso a base está correto. Sou DBA SR e sinceramente, acredito que Hardware não resolve ou mascara o problema. Mais uma vez, a mesma pessoa que se autoproclama sênior e não mostra compreensão nem de júnior, respondendo errado a uma pergunta que ninguém fez. Cícero, por favor, se toque. Já é a segunda vez que te avisamos para não queimar teu próprio filme. Buscando ’cícero neto dba’ no Google me mostra, na primeira página, outra bobagem que você respondeu. Procurando por ‘cícero neto dba postgresql’, aparece ainda outra. Se me aparecesse teu curriculum na frente, essas pesquisas me levariam a descartá‐lo. Todo mundo fala uma bobagem uma vez ou outra; mas persistir no erro e se arrogar uma qualificação que parece injustificada não pega bem. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2014-02-03 Cicero Neto cicero@gmail.com: rever indices locais e orbitais Alguém já entendeu o que o Cícero quer dizer com isso? Estava redigindo uma pergunta à lista quando sua mensagem apareceu - ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um momento me senti emburrecido por não conhecer a diferença entre os dois... TIAGO J. ADAMI http://www.adamiworks.com @tiadami ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30 de janeiro de 2014 15:02, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Mais uma dúvida, estamos com o Postgres rodando em uma máquina virtual, teríamos mais desempenho se estivéssemos rodando em uma máquina física com as mesmas configurações? Não sequestre a thread. Isso é outro assunto, não relacionado à sua primeira pergunta. Todavia, a resposta é *depende*. Hoje pode-se fazer ótimos servidores de bancos de dados virtuais, principalmente com umas máquinas gigantes que andam vendendo por aí (centenas de CPUs e terabytes de memória). Pra fazer uma cola com o assunto origila, isso não muda o fato de que você está abrindo conexões demais ao banco. Físico ou virtual, é conexão demais. Você tem a faca (PgBouncer) e o queijo (PostgreSQL) na mão. É só cortar (diminuir o número de conexões ao banco, nas configurações do PgBouncer). E conte pra nós seu sucesso daqui a pouco. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Olá colegas, depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Abs. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Fico feliz que tenha evoluído com seus resultados! Agora é hora de tirar o segundo truque da cartola do PgBouncer: crie mais um banco de dados virtual apontando pro mesmo banco real, e aponte sua aplicação web para esse banco separado. Assim, você terá uma fila exclusiva para a aplicação web, que certamente tem perfil diferente da outra, e você pode controlar quantas conexões vai reservar pra cada lado. Tente e conte pra nós. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como resolver alta demanda de conexoes
Bom dia pessoal, Temos o seguinte cenário: Durante 2 semanas por ano nosso sistema sofre uma alta demanda de acessos. São 6000 usuários em potencial. De acordo com nosso analista de infra, na última matrícula o postgreSQL foi derrubado por 450 usuários concorrentes. Estamos montando um ambiente PostgreSQL para atender esta demanda. É uma máquina virtual com 32 núcleos e 24GB de Ram. PostgreSQL 9.3 e com PGBouncer. O sistema é PHP/WEB e está sendo montado com 6 máquinas Apache para atender os usuários em potencial. O banco de dados é pequeno, tem 2GB, mas o sistema posssui consultas muito pesadas. Configuramos o PostgreSQL com max_connection de 250. O PGBouncer está recebendo até 2 e passando para o postgres 240. Estamos rodando testes de carga com o JMeter e com 500 usuários o sistema fica muito lento, ocorre erros de conexão(o log do PGbouncer apresenta Could not connect), os 32 núcleos atingem 100% de uso. O que estamos errando na nossa configuração? Abs. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30 de janeiro de 2014 09:50, Wellington Openheimer wopenhei...@gmail.com escreveu: Bom dia pessoal, Temos o seguinte cenário: Durante 2 semanas por ano nosso sistema sofre uma alta demanda de acessos. São 6000 usuários em potencial. De acordo com nosso analista de infra, na última matrícula o postgreSQL foi derrubado por 450 usuários concorrentes. Estamos montando um ambiente PostgreSQL para atender esta demanda. É uma máquina virtual com 32 núcleos e 24GB de Ram. PostgreSQL 9.3 e com PGBouncer. Como são os discos do servidor e como estão configurados? O sistema é PHP/WEB e está sendo montado com 6 máquinas Apache para atender os usuários em potencial. O banco de dados é pequeno, tem 2GB, mas o sistema posssui consultas muito pesadas. Não há nenhuma maneira de agilizar estas consultas? Uma ótima solução seria utilizar o explain pra verificar o plano de execução e otimizar estas consultas.. Se a base é pequena, consultas pesadas seriam meio alheias a este ambiente. Configuramos o PostgreSQL com max_connection de 250. O PGBouncer está recebendo até 2 e passando para o postgres 240. Como estão as outras configurações do PostgreSQL (work_mem, shared_buffers, effective_cache_size, ...)? Estamos rodando testes de carga com o JMeter e com 500 usuários o sistema fica muito lento, ocorre erros de conexão(o log do PGbouncer apresenta Could not connect), os 32 núcleos atingem 100% de uso. Acredito ser um ambiente consideravelmente pequeno pra ocorrer este tipo de problema. Provavelmente as respostas acima nos levarão a uma solução, acredito eu. O que estamos errando na nossa configuração? Abs. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Nós monitoramos o uso de I/O e CPU e não temos problema de disco (Raid 10 em SSD) e a rede é GB. Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: checkpoint_segments = 8 # pgtune wizard 2014-01-29 maintenance_work_mem = 1GB # pgtune wizard 2014-01-29 effective_cache_size = 16GB # pgtune wizard 2014-01-29 work_mem = 20MB # pgtune wizard 2014-01-29 wal_buffers = 4MB # pgtune wizard 2014-01-29 shared_buffers = 5632MB # pgtune wizard 2014-01-29 max_connections = 250 # pgtune wizard 2014-01-29 Qto aos logs, só estamos logando erros. PgBouncer: pool_mode = session server_check_delay = 10 max_client_conn = 2 default_pool_size = 250 server_idle_timeout = 300 Sobre as consultas, são Stored Procedures complexas(que às vezes umas chamam outras) que encapsulam muitas regras de negócio, requerendo muita análise para serem alteradas. Em 30 de janeiro de 2014 09:59, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 30 de janeiro de 2014 09:50, Wellington Openheimer wopenhei...@gmail.com escreveu: Bom dia pessoal, Temos o seguinte cenário: Durante 2 semanas por ano nosso sistema sofre uma alta demanda de acessos. São 6000 usuários em potencial. De acordo com nosso analista de infra, na última matrícula o postgreSQL foi derrubado por 450 usuários concorrentes. Estamos montando um ambiente PostgreSQL para atender esta demanda. É uma máquina virtual com 32 núcleos e 24GB de Ram. PostgreSQL 9.3 e com PGBouncer. Como são os discos do servidor e como estão configurados? O sistema é PHP/WEB e está sendo montado com 6 máquinas Apache para atender os usuários em potencial. O banco de dados é pequeno, tem 2GB, mas o sistema posssui consultas muito pesadas. Não há nenhuma maneira de agilizar estas consultas? Uma ótima solução seria utilizar o explain pra verificar o plano de execução e otimizar estas consultas.. Se a base é pequena, consultas pesadas seriam meio alheias a este ambiente. Configuramos o PostgreSQL com max_connection de 250. O PGBouncer está recebendo até 2 e passando para o postgres 240. Como estão as outras configurações do PostgreSQL (work_mem, shared_buffers, effective_cache_size, ...)? Estamos rodando testes de carga com o JMeter e com 500 usuários o sistema fica muito lento, ocorre erros de conexão(o log do PGbouncer apresenta Could not connect), os 32 núcleos atingem 100% de uso. Acredito ser um ambiente consideravelmente pequeno pra ocorrer este tipo de problema. Provavelmente as respostas acima nos levarão a uma solução, acredito eu. O que estamos errando na nossa configuração? Abs. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: (...) max_connections = 250 # pgtune wizard 2014-01-29 Diminua aqui e a saída pgbouncer para uns 30. Você verá que vai voar. Claro que tem que ver outras coisas como índices, consultas, etc, mas para a questão escalabilidade, menos conexões é mais velocidade no PostgreSQL. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30 de janeiro de 2014 10:41, Wellington Oppenheimer welling...@unifei.edu.br escreveu: Nós monitoramos o uso de I/O e CPU e não temos problema de disco (Raid 10 em SSD) e a rede é GB. Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: checkpoint_segments = 8 # pgtune wizard 2014-01-29 maintenance_work_mem = 1GB # pgtune wizard 2014-01-29 effective_cache_size = 16GB # pgtune wizard 2014-01-29 work_mem = 20MB # pgtune wizard 2014-01-29 wal_buffers = 4MB # pgtune wizard 2014-01-29 shared_buffers = 5632MB # pgtune wizard 2014-01-29 max_connections = 250 # pgtune wizard 2014-01-29 Bom.. imaginando uma situação surreal onde entendamos todo o seu ambiente, que deve ser bem mais complexo do que entendemos até aqui, vamos lá. Com essas configurações e apenas 24GB de RAM, creio que os erros com 500 usuários simultâneos são quase obrigação no caso de overcommit da memória.. Visto que sua base é pequena e considerando não haver problemas de I/O, no caso de demora e crash nas consultas eu faria as seguintes alterações em via de testes: - maintenance_work_mem = 256MB - wal_buffers = manter padrão - checkpoint_timeout = 30min - work_mem = 4MB - shared_buffers = 3072MB ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30 de janeiro de 2014 11:01, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: (...) max_connections = 250 # pgtune wizard 2014-01-29 Diminua aqui e a saída pgbouncer para uns 30. Você verá que vai voar. Claro que tem que ver outras coisas como índices, consultas, etc, mas para a questão escalabilidade, menos conexões é mais velocidade no PostgreSQL. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Pelo que entendi algum problema está derrubando o postgres com 450 conexões concorrentes, vc disse que estão logando os erros, nos envie a mensagem de erros do log do postgres quando caiu o BD. -- Douglas Fabiano Specht ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Flávio, vc disse pra diminuir o max_connection e diminuir o Bouncer para 30. Vamos testar, mas como estamos testando com 500 no Jmeter, isso não vai gerar muita fila de espera, visto que as consultas são pesadas? Douglas No Postgre logou too many clients e foi resolvido com o Bouncer e deu erro de semáforos. Rafael, Quando rodamos os testes, percebemos que não consome memória(não faz Swap), mas sim CPU's, que colam 100%. Em 30 de janeiro de 2014 11:17, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 30 de janeiro de 2014 10:41, Wellington Oppenheimer welling...@unifei.edu.br escreveu: Nós monitoramos o uso de I/O e CPU e não temos problema de disco (Raid 10 em SSD) e a rede é GB. Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: checkpoint_segments = 8 # pgtune wizard 2014-01-29 maintenance_work_mem = 1GB # pgtune wizard 2014-01-29 effective_cache_size = 16GB # pgtune wizard 2014-01-29 work_mem = 20MB # pgtune wizard 2014-01-29 wal_buffers = 4MB # pgtune wizard 2014-01-29 shared_buffers = 5632MB # pgtune wizard 2014-01-29 max_connections = 250 # pgtune wizard 2014-01-29 Bom.. imaginando uma situação surreal onde entendamos todo o seu ambiente, que deve ser bem mais complexo do que entendemos até aqui, vamos lá. Com essas configurações e apenas 24GB de RAM, creio que os erros com 500 usuários simultâneos são quase obrigação no caso de overcommit da memória.. Visto que sua base é pequena e considerando não haver problemas de I/O, no caso de demora e crash nas consultas eu faria as seguintes alterações em via de testes: - maintenance_work_mem = 256MB - wal_buffers = manter padrão - checkpoint_timeout = 30min - work_mem = 4MB - shared_buffers = 3072MB ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Flávio, vc disse pra diminuir o max_connection e diminuir o Bouncer para 30. Vamos testar, mas como estamos testando com 500 no Jmeter, isso não vai gerar muita fila de espera, visto que as consultas são pesadas? Agradecemos não fazer mais top-posting. A resposta imediata à sua pergunta é *não*. Fazer uma fila de requisições no PgBouncer, que é um cara leve, é mais eficiente que enfiar um monte direto no banco de dados, que vai enfileirar processos, acesso a disco, e etc. Menos conexões é mais resultados por segundo no banco. Douglas No Postgre logou too many clients e foi resolvido com o Bouncer e deu erro de semáforos. Erro de semáforos significa que você precisa ajustar seu S.O. Use menos conexóes e não precisa mexer no S.O. Rafael, Quando rodamos os testes, percebemos que não consome memória(não faz Swap), mas sim CPU's, que colam 100%. Menos conexões também resolvem esse sintoma. Não tenha medo. Menos ainda porque você está justamente fazendo testes. Diminua logo esse número de conexões e verá a mágica. Depois, tente aumentar um pouco e diminuir um pouco e veja qual a melhor relação nos TPS do JMeter. Por exemplo, comece com 30, termine o teste, suba pra 60, termine de novo, desça para 15 e termine de novo. Depois, fique no melhor TPS. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Rafael, Quando rodamos os testes, percebemos que não consome memória(não faz Swap), mas sim CPU's, que colam 100%. Pode até ser, dependendo das configurações do S.O., mas, concordando com o Gurgel, eu acho que, de qualquer forma, todas as sugestões são válidas e devem ser testadas. Caso seja diminuído o número de conexões desta forma, também não será necessário mudar muita coias de configurações. []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Pode até ser, dependendo das configurações do S.O., mas, concordando com o Gurgel, eu acho que, de qualquer forma, todas as sugestões são válidas e devem ser testadas. Caso seja diminuído o número de conexões desta forma, também não será necessário mudar muita coias de configuraçõe Estou de acordo com tudo. Só que diminuir o número de conexões é o primeiro passo, pois ele mascara todos os outros. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30-01-2014 14:38, Flavio Henrique Araque Gurgel escreveu: Só que diminuir o número de conexões é o primeiro passo, pois ele mascara todos os outros. Só pra vocês verem como este assunto é recorrente e as pessoas são insistentes, acaba de circular na lista internacional: I would be grateful anyone have a suggestion for my problem. I want to simulate 400 clients sending queries to my Postgresql server. I know the Onde o requerente pergunta em tradução livre Como faço pra simular 400 clientes enviando consultas para meu servidor PostgreSQL... Uma pergunta simples, e que não tem nada a ver com desempenho. A resposta veio de Stephen Frost, um de nossos gurus, é imediata: Unless your server has 400 CPUs, you probably want to use a connection pooler in front of PG. Em tradução livre Exceto se seu servidor tiver 400 CPUs, você provavelmente vai querer usar um aglomerador de conexões na frente de seu PostgreSQL. Basicamente, a regra é 1:1 - Uma conexão para cada CPU disponível, é uma boa regra para primeiro tuning e primeiro teste. Que me abençoe o santo Fábio Telles. Toda variação nessa regra só deve ser feita sob condição de teste. Qualquer outro número, sem teste, é achismo. Portanto, começar o teste do colega com 450 conexões numa máquina de 32 núcleos, não... vai... chegar... a lugar... algum. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Mais uma dúvida, estamos com o Postgres rodando em uma máquina virtual, teríamos mais desempenho se estivéssemos rodando em uma máquina física com as mesmas configurações? Não sequestre a thread. Isso é outro assunto, não relacionado à sua primeira pergunta. Todavia, a resposta é *depende*. Hoje pode-se fazer ótimos servidores de bancos de dados virtuais, principalmente com umas máquinas gigantes que andam vendendo por aí (centenas de CPUs e terabytes de memória). Pra fazer uma cola com o assunto origila, isso não muda o fato de que você está abrindo conexões demais ao banco. Físico ou virtual, é conexão demais. Você tem a faca (PgBouncer) e o queijo (PostgreSQL) na mão. É só cortar (diminuir o número de conexões ao banco, nas configurações do PgBouncer). E conte pra nós seu sucesso daqui a pouco. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
