Listei algumas alternativas para o gerenciamento de conexões abaixo, na ordem do mais para o menos recomendado.
Aumente as conexões permitidas no servidor
O limite total de conexão de entrada no servidor é determinado pelo menor dos limites impostos pelo sistema operacional ou maxIncomingConnections
(também conhecido como maxConns
MongoDB 2.4 e anterior).
Normalmente, as distribuições Linux limitam os descritores de arquivo por processo a 1024, dos quais o MongoDB usará 80% para conexões de entrada (deixando cerca de 819 conexões disponíveis).
Você pode verificar as conexões atuais e disponíveis no mongo
shell via:
db.serverStatus().connections
Para sistemas de produção, é típico ajustar as ulimit
configurações no Linux para permitir conexões mais simultâneas. Para mais práticas recomendadas, recomendo revisar as Notas de produção no manual do MongoDB.
Forneça uma API
Se você estiver gerenciando um servidor compartilhado com limites de recursos, é comum fornecer sua própria API em vez de acesso direto ao banco de dados. Essa abordagem fornece uma camada extra de abstração para que você possa gerenciar o uso de recursos e a implantação do servidor independentemente da configuração do cliente. Por exemplo, você pode mover o servidor de banco de dados ou reconfigurar de um conjunto autônomo para um conjunto de réplicas, e os clientes não precisam estar cientes disso. Você também pode gerenciar limites de recursos personalizados (como conexões por cliente) por meio de sua API, com base nas credenciais que o cliente usa para se conectar.
Reduza o tamanho do conjunto de conexões nos clientes
O MongoDB (como em 2.6) não tem uma opção para limitar as conexões por cliente. Normalmente, os limites do cliente seriam impostos pelo driver (ou seja, definindo o tamanho do conjunto de conexões). Por exemplo, no driver Java, o MongoClient
tamanho máximo padrão do conjunto é 100.
Você já sugeriu que essa não é uma opção desejável, pois não deseja que os clientes mexam com os limites de conexão, mas se for impor um limite do lado do servidor, ainda seria razoável que eles definissem o tamanho do pool adequadamente. Caso contrário, os aplicativos receberão exceções frequentes à medida que você elimina o excesso de conexões.
Monitorar operações do cliente
Se o ajuste de limites no cliente ou servidor não for uma opção, uma alternativa a ser considerada é a implementação de um script para contar conexões simultâneas de clientes (por IP) via db.currentOp()
e eliminar conexões em excesso via db.killOp()
. Você teria que ter muito cuidado para matar apenas solicitações de clientes. O killOp()
comando é um comando de superusuário que também permite eliminar threads de banco de dados internos (o que pode levar a resultados imprevisíveis).
NOTA: Essa abordagem não terá êxito se seus clientes estiverem se conectando através de um gateway compartilhado (ou seja, onde o IP de origem não identifica exclusivamente um cliente).