Mudanças entre as edições de "Uso do PgBouncer com o PJe"
(Criou página com 'O pgBouncer é um gerenciador de conexões com o banco de dados postgresql. É, também, método para otimizar as conexões com o banco de dados. Todos os manuais de bancos de...') |
|||
| Linha 1: | Linha 1: | ||
| − | O | + | O PgBouncer é um gerenciador de conexões com o banco de dados PostgreSQL. É também, um método para otimizar as conexões com o banco de dados. Todos os manuais de bancos de dados informam que a tarefa de criar uma nova conexão com o SGDB (Sistema Gerenciador de Banco de Dados) é um procedimento oneroso, tanto do ponto de vista de alocação e uso dos recursos do banco, como do sistema operacional. |
| − | Infelizmente os recursos são limitados e não há como criar um número muito alto de conexões | + | |
| − | Conforme o aumento do uso do PJe por usuários internos (servidores e juízes) e externos (advogados e população em geral) cria-se a necessidade de aumentar os recursos de infraestrutura alocada para o projeto, então aumenta-se o número de servidores de aplicação ( | + | Infelizmente os recursos são limitados e não há como criar um número muito alto de conexões com o SGDB. Existem alguns estudos sobre o banco de dados PostgreSQL que demonstram que o número máximo de conexões ativas que o banco suporta está contido entre 2 a 4 vezes o número de CPU cores disponíveis para o banco de dados. Não entra nesse cômputo o número de conexões IDLE (esperando comando). |
| − | Por exemplo, o SGDB normalmente completa um mesmo pacote de 10.000 transações mais rápido usando 5 conexões ao invés de 1, porém se usarmos 500 certamente será mais lento. O valor ideal do número de conexões depende muito das particularidades de cada instalação e requer um trabalho de ajuste fino. | + | |
| − | Se imaginarmos um gráfico de performance com o número de conexões no eixo X e TPS (Transações por Segundo) no eixo Y, veremos um crescimento de performance enquanto mais conexões são criadas até atingirmos um ponto de saturação, e neste ponto sua performance cairá abruptamente. | + | Conforme o aumento do uso do PJe por usuários internos (servidores e juízes) e externos (advogados e população em geral) cria-se a necessidade de aumentar os recursos de infraestrutura alocada para o projeto, então aumenta-se o número de servidores de aplicação (JBoss), por exemplo. Com esse crescimento, o número de conexões com o banco de dados também aumenta, contudo há um limite para esse crescimento de conexões ativas com o PostgreSQL. |
| − | Em conjunto temos o | + | |
| − | Esta solução encontra-se instalada em tribunais com grande número de acessos simultâneos, sendo reportado ao CNJ o uso simultâneo com mais de 40 servidores de aplicação | + | Por exemplo, o SGDB normalmente completa um mesmo pacote de 10.000 transações mais rápido usando 5 conexões ao invés de 1, porém se usarmos 500 certamente será mais lento. O valor ideal do número de conexões depende muito das particularidades de cada instalação e requer um trabalho de ajuste fino. |
| + | |||
| + | Se imaginarmos um gráfico de performance com o número de conexões no eixo X e TPS (Transações por Segundo) no eixo Y, veremos um crescimento de performance enquanto mais conexões são criadas até atingirmos um ponto de saturação, e neste ponto sua performance cairá abruptamente. | ||
| + | |||
| + | Em conjunto temos o JBoss e o seu gerenciador de conexões. Com o passar do tempo e maturidade das instalações do PJe pelo Brasil, verificarmos que o JBoss muitas vezes não é eficiente como deveria no gerenciamento do pool de conexões, muitas vezes sendo necessário reiniciar a instância pois, aparentemente, fica indisponível o JVM (Java Virtual Machine). | ||
| + | |||
| + | Esta solução encontra-se instalada em tribunais com grande número de acessos simultâneos, sendo reportado ao CNJ o uso simultâneo com mais de 40 servidores de aplicação JBoss. | ||
| + | |||
| + | *Recursos de Hardware para o PgBouncer* | ||
| + | |||
| + | Este gerenciador de conexões não requer muitos recursos de hardware. Um servidor virtual com 4 cores, 8 GB de memória e 30 GB de disco, dever ser suficiente. Contudo o throughput de rede deve ser monitorado pois este é o gargalo. Neste servidor, instalar o PgBouncer em sua versão mais recente. | ||
| + | |||
| + | O PgBouncer possui 3 modos de gerenciamento do pool de conexões: session, transaction e statement. Apenas o modo transaction será o usado. O modo statement não pode ser usado e o modo session não traz ganho. | ||
| + | |||
| + | Segue abaixo um conjunto de alterações no arquivo de inicialização do PgBouncer. O arquivo de inicialização do PgBouncer, normalmente encontra-se em /etc/pgbouncer/pgbouncer.ini e é um arquivo texto simples e relativamente fácil de ser configurado. Possui duas sessões a saber [dabatases] e [pgbouncer]. Na sessão databases será configurado como o PgBouncer se conecta ao PostgreSQL. Segue um exemplo simples: | ||
Edição das 16h19min de 17 de maio de 2016
O PgBouncer é um gerenciador de conexões com o banco de dados PostgreSQL. É também, um método para otimizar as conexões com o banco de dados. Todos os manuais de bancos de dados informam que a tarefa de criar uma nova conexão com o SGDB (Sistema Gerenciador de Banco de Dados) é um procedimento oneroso, tanto do ponto de vista de alocação e uso dos recursos do banco, como do sistema operacional.
Infelizmente os recursos são limitados e não há como criar um número muito alto de conexões com o SGDB. Existem alguns estudos sobre o banco de dados PostgreSQL que demonstram que o número máximo de conexões ativas que o banco suporta está contido entre 2 a 4 vezes o número de CPU cores disponíveis para o banco de dados. Não entra nesse cômputo o número de conexões IDLE (esperando comando).
Conforme o aumento do uso do PJe por usuários internos (servidores e juízes) e externos (advogados e população em geral) cria-se a necessidade de aumentar os recursos de infraestrutura alocada para o projeto, então aumenta-se o número de servidores de aplicação (JBoss), por exemplo. Com esse crescimento, o número de conexões com o banco de dados também aumenta, contudo há um limite para esse crescimento de conexões ativas com o PostgreSQL.
Por exemplo, o SGDB normalmente completa um mesmo pacote de 10.000 transações mais rápido usando 5 conexões ao invés de 1, porém se usarmos 500 certamente será mais lento. O valor ideal do número de conexões depende muito das particularidades de cada instalação e requer um trabalho de ajuste fino.
Se imaginarmos um gráfico de performance com o número de conexões no eixo X e TPS (Transações por Segundo) no eixo Y, veremos um crescimento de performance enquanto mais conexões são criadas até atingirmos um ponto de saturação, e neste ponto sua performance cairá abruptamente.
Em conjunto temos o JBoss e o seu gerenciador de conexões. Com o passar do tempo e maturidade das instalações do PJe pelo Brasil, verificarmos que o JBoss muitas vezes não é eficiente como deveria no gerenciamento do pool de conexões, muitas vezes sendo necessário reiniciar a instância pois, aparentemente, fica indisponível o JVM (Java Virtual Machine).
Esta solução encontra-se instalada em tribunais com grande número de acessos simultâneos, sendo reportado ao CNJ o uso simultâneo com mais de 40 servidores de aplicação JBoss.
- Recursos de Hardware para o PgBouncer*
Este gerenciador de conexões não requer muitos recursos de hardware. Um servidor virtual com 4 cores, 8 GB de memória e 30 GB de disco, dever ser suficiente. Contudo o throughput de rede deve ser monitorado pois este é o gargalo. Neste servidor, instalar o PgBouncer em sua versão mais recente.
O PgBouncer possui 3 modos de gerenciamento do pool de conexões: session, transaction e statement. Apenas o modo transaction será o usado. O modo statement não pode ser usado e o modo session não traz ganho.
Segue abaixo um conjunto de alterações no arquivo de inicialização do PgBouncer. O arquivo de inicialização do PgBouncer, normalmente encontra-se em /etc/pgbouncer/pgbouncer.ini e é um arquivo texto simples e relativamente fácil de ser configurado. Possui duas sessões a saber [dabatases] e [pgbouncer]. Na sessão databases será configurado como o PgBouncer se conecta ao PostgreSQL. Segue um exemplo simples:
