Muitas conexões abertas no MySQL

Boa Tarde,

Estou usando multi-tenant um banco de dados para cada cliente.
Portanto, se uso um pool com 3 conexões e tenho 50 clientes. Tenho 150 conexões abertas no MySQL.

Pelo que li na documentação do MySQL esse aumento do numero de conexões aumenta a quantidade de memória usada pelo MySQL.

Mas o aumento desse numero de conexões podem causar leaks ou se tornar um gargalo na aplicação?

[quote=RafaelViana]Boa Tarde,

Estou usando multi-tenant um banco de dados para cada cliente.
Portanto, se uso um pool com 3 conexões e tenho 50 clientes. Tenho 150 conexões abertas no MySQL.

Pelo que li na documentação do MySQL esse aumento do numero de conexões aumenta a quantidade de memória usada pelo MySQL.

Mas o aumento desse numero de conexões podem causar leaks ou se tornar um gargalo na aplicação?
[/quote]
Sim…

Qual é o web container em uso?

Apache Tomcat 6

Como eu poderia profilar essa “sobrecarga” no MySQL. O servidor é um CentOS.

A CPU, Memória e I/O não estão sobrecarregados. (verifiquei com o comando top)
Agora instalei o ntop no servidor para verificar se o gargalo não está na rede.

Como você faz para monitorar esse gargalo no MySQL? Tenho o mytop para monitorar as queries.
Vi que o Cacti tem uma boa analise do trafego no MySQL. Qual você usa?

Veja isso resolve - http://fernandofranzini.wordpress.com/2011/06/03/liberacao-das-conexoes-do-datasource-tomcat/

Infelizmente, não.
Não tenho o pool de conexões configurado no Tomcat.
O pool de conexões é feito pelo Hibernate com C3P0.

[quote=RafaelViana]Infelizmente, não.
Não tenho o pool de conexões configurado no Tomcat.
O pool de conexões é feito pelo Hibernate com C3P0.[/quote]

OK…eu desconheço a arquitetura multi-tenant, mas sei que vc precisa identificar o momento exato no qual as conexões precisam ser liberadas.
Como ta seu pool? Não tem com vc configurar o numero de conexões iddle?

Basicamente: Multi-Tenant = mesma aplicação para vários clientes.

Uma das abordagens para se fazer isso é ter um banco de dados só para todos os clientes e com uma chave primária “ligar” logicamente os dados das empresas diferentes dentro do mesmo banco de dados. Nesse caso, eu poderia fazer como está falando de liberar conexões idle pois teria só um banco de dados.

No entanto, eu uso outra abordagem = 1 banco de dados para cada cliente. Então, se eu tenho 50 clientes vão existir 50 banco de dados diferentes no MySQL. O pool está configurado para o minimo de 3 conexões por banco de dados, ou seja, sempre haverá 3 conexões abertas para cada banco de dados. (vou diminuir para duas).

Tenho como usar o mesmo pool de conexões para bancos de dados diferentes? (acho que não)
Ou seja ter cinco conexões abertas com o MySQL (todos os bancos estão no mesmo MySQL) e com essa conexão acessar qualquer um dos bancos de dados?

Vamos supor que eu “mate” as conexões idle não estaria perdendo a vantagem do pool de conexões?

[quote=RafaelViana]Basicamente: Multi-Tenant = mesma aplicação para vários clientes.

Uma das abordagens para se fazer isso é ter um banco de dados só para todos os clientes e com uma chave primária “ligar” logicamente os dados das empresas diferentes dentro do mesmo banco de dados. Nesse caso, eu poderia fazer como está falando de liberar conexões idle pois teria só um banco de dados.

No entanto, eu uso outra abordagem = 1 banco de dados para cada cliente. Então, se eu tenho 50 clientes vão existir 50 banco de dados diferentes no MySQL. O pool está configurado para o minimo de 3 conexões por banco de dados, ou seja, sempre haverá 3 conexões abertas para cada banco de dados. (vou diminuir para duas).

Tenho como usar o mesmo pool de conexões para bancos de dados diferentes? (acho que não)
Ou seja ter cinco conexões abertas com o MySQL (todos os bancos estão no mesmo MySQL) e com essa conexão acessar qualquer um dos bancos de dados?

Vamos supor que eu “mate” as conexões idle não estaria perdendo a vantagem do pool de conexões?[/quote]
Agora entendi…
Não da não…o POOL é para uma dataBase só.
No seu caso, vc vai ter que trabalhar com IDDLE mesmo…deixe no minimo 2 para caso acontecer concorrência repentina.
Outra coisa que vc pode fazer é configurar o tempo de IDDLE, para um tempo menor, fazendo o pool reduzir logo para o IDDLE.
No resto, não existe mais oq fazer.
Sua abordagem esta 100% consistente. Parabéns !

Valeu, legal essa troca de experiência.
Mas, acho que não expressei bem minha dúvida:

Vamos supor que eu tenha apenas uma conexão aberta com o MySQL e uma query leva 1s para executar, se o MySQL tiver 500 conexões abertas irá levar os mesmos 1s?

A media de POOL em uma aplicação devidamente escrita é 1 por 10 sessões logadas.
Vc disse 500 conexões? então da 50000 mil sessões por minutos. Aqui no brazil tem poucas empresas com essa demanda…
Para segurar isso vc vai ter que ter uma puta infra meu…kkkkkkkkkkkkkk
A resposta é - depende do seu hardware e da plataforma, rede, link, cluster, load balancer, failed-over, etc etc…

[quote=FernandoFranzini]A media de POOL em uma aplicação devidamente escrita é 1 por 10 sessões logadas.
Vc disse 500 conexões? então da 50000 mil sessões por minutos. Aqui no brazil tem poucas empresas com essa demanda…
Para segurar isso vc vai ter que ter uma puta infra meu…kkkkkkkkkkkkkk
A resposta é - depende do seu hardware e da plataforma, rede, link, cluster, load balancer, failed-over, etc etc…
[/quote]

Desculpa, se minhas perguntas são meio básicas… é que essa parte de infra não é bem minha área e nunca trabalhei em empresas de grande porte para mensurar se 500 conexões é muito ou não =)

É que tem aquele “probleminha” de um banco de dados por cliente rsrs Então considerando 250 clientes (numero comum) = 500 conexões (se eu deixar duas conexões no pool por cliente)
No entanto, dessas 500 conexões a maioria ficaria boa parte do tempo como SLEEP.

Pelo que eu entendi do pool de conexões, eu deixo duas conexões abertas no banco (mesmo que em Sleep), pois se o cliente necessita fazer uma consulta a conexão com o banco já está aberta. (já que a criação de uma nova conexão é uma tarefa demorada), certo?

Mesmo as threads do banco de dados estando como SLEEP prejudicam a perfomance?

Se vc ta falando é requisito e restrições…ok!

[quote]No entanto, dessas 500 conexões a maioria ficaria boa parte do tempo como SLEEP.
[/quote]
Sim.

Eu não sei como funciona seu POOL, eu sei como funciona o meu ! kkkk Normalmente é assim,

  • quando a solução requer uma conexão acima do numero configurado no IDDLE , o pool abre todas as conexões configurados no POOL.
  • quando a solução requer uma conexão acima do numero configurado no POOL, o pool abre todas as conexões configurados no MAX.
  • Passando o tempo sem usar, ele volta para o numero IDDLE.
    E assim vai…pode acontecer varianças entre provedores de pool…favor consultar a doc do seu !

Meu querido, fica traquilo que o pool é a melhor estrategia de conexão!
A unica coisa q vc tem q se preocupar e não segurar um conexão a toa!!!..que é algo que eu vejo com fator de peso pelo seu cenário. Favor veja se a solução liberar as conexões logo apos serem usada para poder compartilhar logo com os outros usuários.
Segue o algoritmo base

  1. Pega a conexão do Pool.
  2. executa o SQL
  3. Cacher a o resultado numa CacheRowSet, List, Wharever
  4. Libera a conexão para o próximo
  5. Manipular e trabalhar como o resultado no CacheRowSet, List, Wharever
    Se vc estabelecer este padrão na sua camada de acesso…a coisa vai funcionar bem. É aqui que muitos erram…