Como otimizar as ligações à base de dados do Immich para contentores simultâneos

Otimize as ligações à base de dados do Immich medindo a procura total de sessões em todos os processos do Immich e noutros clientes PostgreSQL, em vez de aumentar primeiro max_connections. A base de dados precisa de sessões suficientes para a carga de trabalho real, além de margem administrativa, mas uma concorrência excessiva pode aumentar o consumo de memória e a contenção sem tornar as consultas mais rápidas.

Num servidor doméstico com vários contentores, registe as ligações ativas, inativas e em espera, juntamente com a latência das consultas, a utilização da CPU, a memória e a latência do armazenamento, durante a utilização normal e durante o arranque simultâneo. Um erro de “demasiados clientes” pode resultar da configuração agregada, de outro serviço ou de um ciclo contínuo de reinícios, mesmo quando um único contentor do Immich parece utilizar poucos recursos.

Faça o inventário de todos os clientes PostgreSQL antes de alterar os limites

Enumere cada processo ou réplica do servidor Immich, tarefa de migração/manutenção, trabalho de cópia de segurança, ferramenta de monitorização e aplicação não relacionada que estabeleça ligação à mesma instância PostgreSQL. Sempre que possível, atribua-lhes utilizadores de base de dados separados, para que pg_stat_activity possa mostrar quem mantém as sessões. Registe o max_connections atual e preserve uma via administrativa para a resposta a incidentes.

Uma discussão sobre “demasiados clientes” do Immich inclui um comentário do projeto segundo o qual o Immich utilizava um conjunto predefinido de 10 ligações nessa versão. Uma discussão separada de 2026 indica que vários processos de trabalho do Immich podem manter, cada um, o seu próprio conjunto. Considere estes valores como contexto de implementação específico da versão, e não como um número a multiplicar cegamente em versões futuras. Se a base de dados já estiver próxima do limite de ligações enquanto o Immich está inativo, identifique o responsável por essas sessões antes de ajustar o Immich. Se houver poucas sessões ativas, mas as consultas forem lentas, a quantidade de ligações pode ser um sintoma da latência do armazenamento ou das consultas, e não o principal estrangulamento.

Crie um orçamento de ligações com base na concorrência medida

Reserve sessões para a administração da base de dados, ferramentas de cópia de segurança/restauro, migrações e monitorização.

Depois, distribua as restantes ligações da aplicação pelo número de processos do Immich e de outras aplicações em execução simultânea. O objetivo é ter um conjunto suficientemente grande para que o trabalho normal não fique desnecessariamente à espera, mas não maior do que aquilo que a base de dados consegue executar de forma eficiente.

Uma análise do dimensionamento de conjuntos de ligações do PostgreSQL descreve o conjunto ideal como suficientemente grande para a procura normal, mas tão pequeno quanto possível, porque menos sessões de backend reduzem a contenção. Aplique esse princípio à procura observada do Immich, em vez de copiar o tamanho de um conjunto de ligações de servidor Web de outra carga de trabalho.

Se a versão do Immich não expuser um controlo suportado do tamanho do conjunto de ligações, não altere componentes internos apenas para atingir um número-alvo. Controle o que puder: o número de réplicas da aplicação, os clientes não relacionados, o momento dos reinícios, a sobreposição das cópias de segurança e a capacidade da base de dados. Reavalie a configuração suportada quando as versões mudarem.

Reduza a criação e destruição de ligações e a espera na base de dados antes de adicionar mais sessões

Desfasar o arranque dos contentores para que o Immich, as ferramentas de análise, os trabalhos de cópia de segurança e outras aplicações não restabeleçam todos as ligações nem executem migrações em simultâneo. Utilize verificações de estado e prontidão que aguardem até o PostgreSQL estar utilizável, mas evite ciclos de novas tentativas demasiado frequentes, que criem uma avalanche de ligações enquanto a base de dados ainda está a recuperar.

O guia da ZimaSpace sobre a segurança de uma base de dados externa do Immich define um limite importante: quando o PostgreSQL é separado da pilha predefinida, as responsabilidades relativas à versão, às extensões, aos privilégios, às cópias de segurança e ao restauro tornam-se explícitas. Não introduza um proxy de ligações ou um servidor de base de dados adicional apenas para ocultar consultas lentas ou um armazenamento saturado.

Se muitas sessões estiverem inativas e o número elevado de aplicações for legítimo, um gestor de ligações pode reduzir as sessões de backend em algumas arquiteturas PostgreSQL, mas apenas depois de testar a versão exata do Immich, as migrações, a semântica das transações e o comportamento das instruções preparadas. O agrupamento de ligações não substitui a correção de um cliente descontrolado ou de uma base de dados sobrecarregada.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valide com carregamentos, pesquisas, tarefas e reinícios simultâneos

Crie um pico reproduzível: execute carregamentos móveis representativos, uma ação de pesquisa ou navegação mais exigente e a combinação normal de tarefas em segundo plano, enquanto os outros contentores esperados estão ativos. Registe o número de ligações por utilizador/estado, os erros de aquisição ou de pedidos, a latência das consultas, a utilização da CPU e da memória da base de dados e a latência do disco. Depois, repita o teste após uma única alteração.

Uma configuração aprovada mantém as sessões abaixo do limite de falha, com margem administrativa, evita erros de “demasiados clientes”, mantém a latência das consultas dentro do objetivo definido para a habitação e permite que as filas sejam esvaziadas após o pico. Só se justificam mais ligações quando os pedidos estão efetivamente à espera de uma sessão, enquanto a base de dados ainda dispõe de capacidade de CPU, memória e E/S.

Reinicie a pilha de aplicações e, em seguida, o anfitrião uma vez, para testar o maior pico de ligações. Se a falha ocorrer apenas durante o arranque, corrija a ordem de inicialização e o comportamento das novas tentativas, em vez de aumentar o limite permanente. Se as sessões se acumularem ao longo do tempo, registe os utilizadores e as consultas responsáveis e investigue esse padrão de fuga, fornecendo as versões e as evidências relativas ao estado das ligações.