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 = 20000 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 <[email protected]>escreveu: > Em 30 de janeiro de 2014 09:50, Wellington Openheimer < > [email protected]> 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é 20000 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 >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > []'s > > _______________________________________________ > pgbr-geral mailing list > [email protected] > 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
