Mudanças entre as edições de "Uso do PgBouncer com o PJe"

De PJe
Ir para: navegação, pesquisa
(Desabilitar prepared_statemets no PJe)
 
(24 edições intermediárias de 2 usuários não apresentadas)
Linha 1: Linha 1:
 
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.
 
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).
+
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. 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.  
 
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.  
Linha 9: Linha 9:
 
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.  
 
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).
+
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, verificamos 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.
 
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'''
+
=== 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.
+
Este gerenciador de conexões não requer muitos recursos de hardware. Um servidor virtual com 4 cores, 4 GB de memória e 30 GB de disco, são suficientes. Contudo o ''throughput'' de rede deve ser monitorado pois este é o gargalo. Neste servidor, instalar o PgBouncer em sua versão mais recente. É recomendado que a máquina de instalação do pgBouncer seja separada do banco.
  
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.
+
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:
+
Segue abaixo um conjunto de alterações no arquivo de inicialização do PgBouncer. O arquivo de inicialização, 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''].  
  
font color="#00FF00">
+
Na sessão '''[''databases'']''' será configurado como o PgBouncer se conecta ao PostgreSQL, segue um exemplo simples:
{|bgcolor="#000000" {{table width="70%"}}
+
|-
+
|Pje = host = 10.1.1.1 port = 5432
+
|}
+
</font>
+
  
 +
  Pje = host = 10.1.1.1 port = 5432
  
Já na seção [pgbouncer] encontram-se a maior parte das configurações:
+
Já na seção '''[''pgbouncer'']''' encontram-se a maior parte das configurações:
  
logfile = /var/log/pgbouncer/pgbouncer.log
+
  logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid
+
  pidfile = /var/run/pgbouncer/pgbouncer.pid
  
listen_addr = *
+
  listen_addr = *
listen_port = 6432
+
  listen_port = 6432
  
auth_type = trust
+
  auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt
+
  auth_file = /etc/pgbouncer/userlist.txt
  
admin_users = postgres
+
  admin_users = postgres
stats_users = stats, postgres
+
  stats_users = stats, postgres
  
pool_mode = transaction
+
  pool_mode = transaction
  
server_reset_query = DISCARD ALL
+
  server_reset_query = DISCARD ALL
  
ignore_startup_parameters = extra_float_digits,application_name
+
  ignore_startup_parameters = extra_float_digits,application_name
server_check_query = select 1
+
  server_check_query = select 1
server_check_delay = 30
+
  server_check_delay = 30
  
max_client_conn = 10000
+
  max_client_conn = 10000
default_pool_size = 130
+
  default_pool_size = 130
min_pool_size = 80
+
  min_pool_size = 80
  
 +
  idle_transaction_timeout = 180
  
idle_transaction_timeout = 180
+
<font color=red>'''NOTA:'''</font> Importante observar os parâmetros ''max_client_conn'' e ''default_pool_size''. O primeiro informa quantas conexões estarão disponíveis para os servidores de aplicação JBoss e outros clientes. O segundo informa o número máximo de conexões com o banco de dados. Estes valores devem ser configurados de acordo com a sua instalação e não são valores de referências.
 +
 
 +
=== Desabilitar prepared_statemets no PJe ===
 +
 
 +
Contudo, para usarmos o PgBouncer no modo ''transaction'', devemos desabilitar a ''feature prepared statements'' do hibernate usado no PJe. Para desabilitarmos o ''prepared statements'' no PJe é necessário usar o driver jdbc 9.3 ou superior e alterar o ''datasource'' no JBoss, incluindo as seguintes diretivas:
 +
 
 +
  <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
 +
  <connection-property name="autoCommit">false</connection-property>
 +
  <prepared-statement-cache-size>0</prepared-statement-cache-size>
 +
  <shared-prepared-statements>false</shared-prepared-statements>
 +
 
 +
Para o JBOSS 7 ou Wildfly 9 ou superior
 +
 
 +
  <xa-datasource-property name="prepareThreshold">
 +
      0
 +
  </xa-datasource-property>
 +
  <statement>
 +
      <prepared-statement-cache-size>0</prepared-statement-cache-size>
 +
      <share-prepared-statements>false</share-prepared-statements>
 +
  </statement>
 +
 
 +
 
 +
Agora devemos apontar o endereço do servidor PostgreSQL usado no datasource implantado no JBoss para o PgBouncer:
 +
 
 +
  <xa-datasource-property name="ServerName">10.1.1.2</xa-datasource-property>
 +
  <xa-datasource-property name="PortNumber">6432</xa-datasource-property>

Edição atual tal como às 10h56min de 14 de dezembro 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. 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, verificamos 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.

[editar] Recursos de Hardware para o PgBouncer

Este gerenciador de conexões não requer muitos recursos de hardware. Um servidor virtual com 4 cores, 4 GB de memória e 30 GB de disco, são suficientes. Contudo o throughput de rede deve ser monitorado pois este é o gargalo. Neste servidor, instalar o PgBouncer em sua versão mais recente. É recomendado que a máquina de instalação do pgBouncer seja separada do banco.

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, 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:

 Pje = host = 10.1.1.1 port = 5432

Já na seção [pgbouncer] encontram-se a maior parte das configurações:

 logfile = /var/log/pgbouncer/pgbouncer.log
 pidfile = /var/run/pgbouncer/pgbouncer.pid
 listen_addr = *
 listen_port = 6432
 auth_type = trust
 auth_file = /etc/pgbouncer/userlist.txt
 admin_users = postgres
 stats_users = stats, postgres
 pool_mode = transaction
 server_reset_query = DISCARD ALL
 ignore_startup_parameters = extra_float_digits,application_name
 server_check_query = select 1
 server_check_delay = 30
 max_client_conn = 10000
 default_pool_size = 130
 min_pool_size = 80
 idle_transaction_timeout = 180

NOTA: Importante observar os parâmetros max_client_conn e default_pool_size. O primeiro informa quantas conexões estarão disponíveis para os servidores de aplicação JBoss e outros clientes. O segundo informa o número máximo de conexões com o banco de dados. Estes valores devem ser configurados de acordo com a sua instalação e não são valores de referências.

[editar] Desabilitar prepared_statemets no PJe

Contudo, para usarmos o PgBouncer no modo transaction, devemos desabilitar a feature prepared statements do hibernate usado no PJe. Para desabilitarmos o prepared statements no PJe é necessário usar o driver jdbc 9.3 ou superior e alterar o datasource no JBoss, incluindo as seguintes diretivas:

 <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
 <connection-property name="autoCommit">false</connection-property>
 <prepared-statement-cache-size>0</prepared-statement-cache-size>
 <shared-prepared-statements>false</shared-prepared-statements>

Para o JBOSS 7 ou Wildfly 9 ou superior

 <xa-datasource-property name="prepareThreshold">
     0
 </xa-datasource-property>
 <statement>
     <prepared-statement-cache-size>0</prepared-statement-cache-size>
     <share-prepared-statements>false</share-prepared-statements>
 </statement>


Agora devemos apontar o endereço do servidor PostgreSQL usado no datasource implantado no JBoss para o PgBouncer:

 <xa-datasource-property name="ServerName">10.1.1.2</xa-datasource-property>
 <xa-datasource-property name="PortNumber">6432</xa-datasource-property>
Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Informações Gerais
Aplicativos PJe
Manuais
Suporte
Ferramentas