java - springboot_1.0 - configuração simples do pool de conexões jdbc tomcat

java-springboot 1.x - configuração do conjunto de conexões jdbc Tomcat

ambiente

  • jdk 1.8
  • bota de mola 1.56
  • meubot 3.5.3

fundo

Vendo que as pessoas muitas vezes configuram incorretamente os parâmetros do pool de conexões ou confundem a configuração do springboot1.0 e 2.0, aqui está uma explicação de como configurar e usar o pool de conexões padrão do Tomcat para o springboot 1.0.

Como configurar e usar corretamente o pool de conexões do Tomcat em bootstrap.yml?

É incorreto configurar diretamente os parâmetros do pool de conexões em string.datasource e a configuração não terá efeito.
Nota: Cole o seguinte conteúdo no arquivo de configuração yml, onde — é a tag inicial do novo arquivo de configuração; spring.profiles pode especificar seus próprios parâmetros de ambiente;

---
spring.profiles: default
spring:
  datasource:
    tomcat :
      initialSize: 1  #池启动时打开的连接数
      maxActive: 20    #打开的最大连接数
      maxIdle: 5      #最大空闲连接数
      minIdle: 1      #打开连接的最小数量
      maxWait: 30000  #获取连接时抛出SQLException之前等待的时间(以毫秒为单位)
      testOnBorrow: false   #如果在请求连接时进行验证,则为True
      testOnReturn: false   #如果在返回连接时进行验证,则为True
      testWhileIdle: true   #如果验证在连接未使用(空闲)时发生,则为True
      timeBetweenEvictionRunsMillis: 60000  #配置间隔多久才进行一次检测,检测需要关闭的空闲连接,单位是毫秒
      minEvictableIdleTimeMillis: 300000  #配置一个连接在池中最小生存的时间,单位是毫秒(与 timeBetweenEvictionRunsMillis 配合使用)
      validationQueryTimeout: 1000    #连接验证查询失败前的超时(以秒为单位)
      validationQuery: select 1 AS count    #检测连接是否有效的SQL

Configuração padrão do pool de conexões do Tomcat

Objetos-chave usados ​​pelo código do pool de conexões

  • Configuração padrão: org.apache.tomcat.jdbc.pool.PoolProperties;
  • Pacote: tomcat-jdbc-8.5.16.jar
  • Para obter detalhes sobre itens de configuração, consulte: tomcat-jdbc-8.5.16.jar!\org\apache\tomcat\jdbc\pool\mbeans-descriptors.xml
  • Objeto do conjunto de conexões: org.apache.tomcat.jdbc.pool.ConnectionPool
  • Obtenha o método de conexão: org.apache.tomcat.jdbc.pool.ConnectionPool#getConnection()
    public static final int DEFAULT_MAX_ACTIVE = 100;
    private volatile int defaultTransactionIsolation = DataSourceFactory.UNKNOWN_TRANSACTIONISOLATION;
    private volatile int initialSize = 10;
    private volatile int maxActive = DEFAULT_MAX_ACTIVE;
    private volatile int maxIdle = maxActive;
    private volatile int minIdle = initialSize;
    private volatile int maxWait = 30000;
    private volatile String validationQuery;
    private volatile int validationQueryTimeout = -1;
    private volatile String validatorClassName;
    private volatile Validator validator;
    private volatile boolean testOnBorrow = false;
    private volatile boolean testOnReturn = false;
    private volatile boolean testWhileIdle = false;
    private volatile int timeBetweenEvictionRunsMillis = 5000;
    private volatile int numTestsPerEvictionRun;
    private volatile int minEvictableIdleTimeMillis = 60000;
    private volatile boolean accessToUnderlyingConnectionAllowed = true;
    private volatile boolean removeAbandoned = false;
    private volatile int removeAbandonedTimeout = 60;
    private volatile boolean logAbandoned = false;
    private volatile String password;
    private volatile String username;
    private volatile long validationInterval = 3000;
    private volatile boolean jmxEnabled = true;
    private volatile String initSQL;
    private volatile boolean testOnConnect =false;
    private volatile boolean fairQueue = true;
    private volatile boolean useEquals = true;
    private volatile int abandonWhenPercentageFull = 0;
    private volatile long maxAge = 0;
    private volatile boolean useLock = false;
    private volatile int suspectTimeout = 0;
    private volatile boolean alternateUsernameAllowed = false;
    private volatile boolean commitOnReturn = false;
    private volatile boolean rollbackOnReturn = false;
    private volatile boolean useDisposableConnectionFacade = true;
    private volatile boolean logValidationErrors = false;
    private volatile boolean propagateInterruptState = false;
    private volatile boolean ignoreExceptionOnPreLoad = false;
    private volatile boolean useStatementFacade = true;

Instruções de configuração

  • maxActive="100"

    indica o número máximo de conexões que podem ser obtidas do conjunto de conexões sob condições simultâneas.
  • maxIdle="30"

    Se maxActive=100 for atingido durante a simultaneidade,então o conjunto de conexões deverá obter 100 conexões do banco de dados para uso do aplicativo. Quando o aplicativo fechar a conexão, devido a maxIdle=30, nem todas as conexões serão retornado ao banco de dados e 30 conexões permanecerão no pool de conexões e o status será inativo.
    A conexão correspondente a maxIdle é na verdade uma conexão longa mantida pelo pool de conexões, que também é a parte onde o pool de conexões aproveita.Em teoria, conexões mais longas podem ser mantidas, o que pode responder mais rápido quando as solicitações do aplicativo são feitas, mas também muitas conexões são mantidas, mas consumirão muitos recursos do banco de dados, então maxIdle não é tão grande quanto possível
  • minIdle=”2”

    não é efetivo por padrão. Isso significa que quando há poucas conexões minIdle no pool de conexões, o thread de monitoramento do sistema iniciará a função suplementar. Geralmente, não iniciamos o thread suplementar.
  • removeAbandoned = "true"

    se deve ser reciclado após o limite de tempo
  • removeAbandonedTimeout="60"

    tempo limite; a unidade é a segunda
  • logAbandoned = "true"

    log de erro de saída ao fechar a conexão abandonada.
    Às vezes, os criadores de programas descuidados esquecem de fechar a conexão após obter a conexão do pool de conexões, de modo que o pool de conexões alcance gradualmente maxActive até que o pool de conexões não possa fornecer serviços. Pools de conexões modernos geralmente fornecem uma verificação "inteligente", mas quando removeAbandoned="true" é definido, quando o número de conexões no pool de conexões atinge (getNumIdle() < 2) e (getNumActive() > getMaxActive() - 3) A reciclagem da conexão será iniciada e a conexão cujo tempo de atividade exceder removeAbandonedTimeout="60" será reciclada. Ao mesmo tempo, se logAbandoned="true" estiver definido como true, o programa imprimirá o log enquanto recicla a conexão. removeAbandoned é uma função avançada do pool de conexões. Em teoria, essa configuração não deveria aparecer no ambiente de produção real, porque às vezes o aplicativo executa transações longas. Nesse caso, ela pode ser reciclada por engano pelo pool de conexões. Essa configuração geralmente é utilizado na etapa de teste do programa, para localizar o local específico do código do vazamento de conexão, ele é aberto, e o fechamento da conexão no ambiente de produção deve ser garantido pelo próprio programa.
    Geralmente, existem várias situações que exigem removeAbandoned: O código não libera finalmente a conexão, mas todos nós usamos sqlmapClientTemplate, e a camada inferior tem o processo de liberação da conexão e encontra um impasse no banco de dados
    . Anteriormente, o processo de armazenamento de back-end bloqueava a tabela, o que fazia com que todos os pools de conexões no cluster front-end fossem bloqueados e o processamento de negócios subsequente falhasse porque a conexão não pôde ser obtida.
  • inicialSize

    O número de conexões iniciais criadas quando o pool de conexões é iniciado (o valor padrão é 0)
  • maxWait

    O tempo máximo de espera, quando não há conexão disponível, o tempo máximo para o pool de conexões aguardar a liberação da conexão. Se o limite de tempo for excedido, uma exceção será lançada. Se você definir -1, significa espera infinita (o padrão é infinito, ajuste-o para 60.000 ms, para evitar uso insuficiente do pool de threads, fazendo com que a solicitação seja interrompida indefinidamente)
  • poolPreparedStatements

    habilita o pool preparado (o padrão é falso, não ajustado, após o teste, o desempenho após a abertura não é tão bom quanto o fechamento).
  • maxOpenPreparedStatements

    O número máximo de conexões simultâneas após a abertura do pool preparado (o padrão é ilimitado, igual ao acima, não configurado)
  • minEvictableIdleTimeMillis

    A conexão no pool de conexões ficou inativa por um período de tempo e foi removida do pool de conexões (o padrão é 30 minutos, que pode ser ajustado adequadamente e precisa estar relacionado à configuração da política do servidor back-end)
  • minEvictableIdleTimeMillis

    O tempo ocioso de conexões no pool de conexões, em milissegundos


  • O tempo do thread de despejo definido por timeBetweenEvictionRunsMillis , a unidade é ms
    e o thread de verificação de despejo
    será aberto somente quando for maior que 0 O número de conexões no pool até minIdle
  • testOnBorrow

    , como o nome sugere, serve para realizar a verificação verifyObject na conexão obtida quando empréstimoObject é processado.
  • Como o nome sugere, testOnReturn

    está executando returnObject para validarObject na conexão retornada.Pessoalmente, acho que é de pouca importância para o gerenciamento do pool de conexões de banco de dados.
  • O foco de testWhileIdle

    é que em GenericObjectPool, um thread de temporização Evict TimerTask é configurado para gerenciamento de pool (definindo o parâmetro timeBetweenEvictionRunsMillis>0), e o link no pool de threads é validadoObject regularmente, e o link inválido é fechado. chame garantirMinIdle, estabeleça corretamente um link para garantir o número mínimo de conexões minIdle
  • ValidateQuery

    representa o SQL verificado, que é usado para verificar se a conexão é válida. O requisito é uma instrução de consulta. Se ValidateQuery for nulo, testOnBorrow, testOnReturn e testWhileIdle não funcionarão
  • ValidateQueryTimeout

    significa que quando a verificação é realizada, ela é definida por meio da instrução, statement.setQueryTimeout(validationQueryTimeout)
  • numTestsPerEvictionRun

    representa o número de links a serem verificados a cada vez.Recomenda-se defini-lo tão grande quanto maxActive para que todos os links possam ser verificados efetivamente a cada vez.

Como verificar se a configuração dos parâmetros do pool de conexões entra em vigor?

Injete um objeto de fonte de dados e imprima o conteúdo do objeto para verificar se os parâmetros são válidos.

@Autowired
private DataSource ds;

public void test() throws IOException {
    System.out.println(ds.getClass());
    System.out.println(ds.toString());
}

Veja se vários atributos-chave são consistentes com a configuração:
os atributos-chave são: maxActive=3; maxIdle=2; minIdle=1; initialSize=1; maxWait=3000;

class org.apache.tomcat.jdbc.pool.DataSource
org.apache.tomcat.jdbc.pool.DataSource@2123a61c{ConnectionPool[defaultAutoCommit=null; defaultReadOnly=null; defaultTransactionIsolation=-1; defaultCatalog=null; driverClassName=org.postgresql.Driver; maxActive=3; maxIdle=2; minIdle=1; initialSize=1; maxWait=3000; testOnBorrow=false; testOnReturn=false; timeBetweenEvictionRunsMillis=60000; numTestsPerEvictionRun=0; minEvictableIdleTimeMillis=300000; testWhileIdle=true; testOnConnect=false; password=********; url=********; validationQuery=select 1 AS count; validationQueryTimeout=1000; validatorClassName=null; validationInterval=3000; accessToUnderlyingConnectionAllowed=true; removeAbandoned=false; removeAbandonedTimeout=60; logAbandoned=false; connectionProperties=null; initSQL=null; jdbcInterceptors=null; jmxEnabled=true; fairQueue=true; useEquals=true; abandonWhenPercentageFull=0; maxAge=0; useLock=false; dataSource=null; dataSourceJNDI=null; suspectTimeout=0; alternateUsernameAllowed=false; commitOnReturn=false; rollbackOnReturn=false; useDisposableConnectionFacade=true; logValidationErrors=false; propagateInterruptState=false; ignoreExceptionOnPreLoad=false; useStatementFacade=true; }

O pool de conexões Pgsql não pode alocar links e solucionar problemas

informações de exceção

org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [Thread-15] Timeout: Pool empty. Unable to fetch a connection in 3 seconds, none available[size:1; busy:1; idle:0; lastwait:2999].

Visualize links existentes e execute SQL por meio de tabelas do sistema

Quando a exceção acima ocorrer no sistema, abra o console para executar o script:

select * from pg_stat_activity;

A coluna de consulta é o SQL que está sendo executado; analisar o SQL que está sendo executado geralmente pode localizar o código de negócios que aciona o SQL;

Resumir

A configuração do pool de conexões precisa considerar vários fatores, como: Qual o número máximo de conexões com o banco de dados? Quantos microsserviços são necessários para acessar este banco de dados? Quantas instâncias de cada microsserviço são implantadas? etc.

  • Por exemplo, se usarmos apenas uma instância de banco de dados, o número máximo de conexões será 1.600;
  • Existem 60 instâncias implantadas no cluster, todas elas precisam acessar o banco de dados;
  • Então a configuração maxActive de cada serviço deve ser menor que 26 (1600/20),
    na configuração real também é necessário considerar os links reservados para expansão, então maxActive=20 é uma configuração razoável;

Acho que você gosta

Origin blog.csdn.net/xxj_jing/article/details/131813460
Recomendado
Clasificación