Quantas tarefas simultâneas consegue o Immich suportar antes de a capacidade de resposta da pesquisa diminuir?

O Immich não tem um número universal de tarefas seguro; a pesquisa degrada-se quando os trabalhadores concorrentes saturam o recurso de que também necessitam os pedidos interativos.

Dois servidores podem executar o mesmo número de tarefas de miniaturas, metadados e aprendizagem automática e, ainda assim, apresentar latências de pesquisa muito diferentes. O limite útil é, portanto, a carga de trabalho mista mais elevada que mantém um objetivo definido de resposta interativa enquanto a fila continua a esvaziar-se.

O número de tarefas não descreve a carga de trabalho

Um valor de concorrência é apenas um limite de trabalhadores, não uma medida direta da pressão. A geração de miniaturas, a transcodificação de vídeo, a extração de metadados e a inferência de aprendizagem automática realizam diferentes volumes de trabalho computacional e de armazenamento. Quatro tarefas ligeiras de metadados podem deixar a interface responsiva, enquanto duas tarefas de vídeo ocupam o mesmo anfitrião de forma muito mais intensa.

Um relato da comunidade sobre a elevada utilização de CPU pela aprendizagem automática descreve a redução das tarefas concorrentes após uma grande importação, o que diminuiu a carga, mas prolongou o tempo de conclusão. Essa observação confirma a principal compensação: uma concorrência mais baixa protege a capacidade de resposta em primeiro plano ao permitir que o trabalho pendente seja processado mais lentamente, não ao eliminar o trabalho subjacente.

Trate cada fila como uma classe de carga de trabalho. Registe que tarefas estão ativas, que tipo de multimédia processam e se existe aceleração disponível. Um total seguro derivado de pequenos JPEG não pode ser aplicado a fotografias RAW ou vídeos longos, porque o trabalho representado por cada posição mudou.

A pesquisa degrada-se no primeiro ponto de saturação partilhado

A pesquisa interativa atravessa várias camadas partilhadas: o pedido chega à aplicação, a base de dados seleciona os resultados, as miniaturas são lidas e um cliente apresenta-as. Os trabalhadores em segundo plano podem competir em mais do que uma camada. A primeira camada saturada torna-se o limite prático de concorrência, mesmo quando todos os contentores continuam saudáveis.

Uma discussão sobre o desempenho do Immich descreve o carregamento tardio de miniaturas num anfitrião com largura de banda nominal adequada, ilustrando por que motivo a velocidade da ligação, por si só, não consegue identificar o estrangulamento. O escalonamento da CPU, as leituras da base de dados, a latência do sistema de ficheiros e a entrega ao cliente continuam a ser hipóteses até as medições mostrarem qual o tempo de espera que aumenta durante o pedido lento.

A utilização deve ser associada ao atraso. Uma CPU muito utilizada com latência de pesquisa estável pode representar uma saturação produtiva, enquanto uma utilização moderada da CPU acompanhada por um aumento do tempo de espera do disco pode identificar uma fila de armazenamento. A pressão sobre a memória é relevante quando a recuperação de memória ou a troca acrescentam atraso, não apenas porque o sistema operativo utiliza a RAM disponível como cache.

A capacidade de pesquisa pode atrasar-se sem consultas de pesquisa lentas

Uma consulta rápida pode devolver uma coleção pesquisável incompleta quando os novos recursos ainda não terminaram o trabalho de indexação. Por outro lado, todos os itens podem já estar indexados enquanto as consultas são lentas devido à contenção no acesso à base de dados ou ao armazenamento. Chamar a ambas as condições “degradação da pesquisa” oculta dois resultados diferentes e conduz ao ajuste de concorrência errado.

A explicação da ZimaSpace sobre o percurso de dados do Immich separa a aceitação do carregamento, a disponibilidade da pré-visualização e a recuperação semântica como resultados distintos. Essa distinção é essencial durante os testes de carga: o momento em que um ficheiro chega não pode substituir o momento em que a sua representação se torna elegível para pesquisa.

Acompanhe dois relógios para um grupo fixo de importação. Um mede a latência das consultas interativas relativamente a fotografias de controlo já indexadas; o outro mede o tempo até as fotografias recém-importadas aparecerem em pesquisas predeterminadas. O primeiro protege a experiência do utilizador ativo, enquanto o segundo mostra o custo de débito resultante da redução da concorrência.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Encontre o limite com um teste por etapas, não por tentativa

Crie um lote de multimédia representativo e escolha três pesquisas fixas que devolvam recursos conhecidos. Comece com um trabalhador em cada fila ativa, execute a importação e registe a latência mediana e a latência da cauda lenta da pesquisa, a taxa de esvaziamento da fila, a CPU, a pressão sobre a memória, o débito da rede e o tempo de espera do armazenamento durante o mesmo período de observação.

As orientações gerais sobre estrangulamentos recomendam correlacionar as alterações da carga de trabalho com os tempos de espera da CPU, da memória, do disco, da rede e das dependências, em vez de escolher o gráfico que parece mais ocupado. Aumente apenas um controlo de concorrência por execução. Repetir a mesma sequência de pesquisas e o mesmo grupo de multimédia mantém identificável a variável alterada.

Pare na primeira etapa em que o objetivo de pesquisa da cauda lenta falhar, o servidor começar a utilizar memória de troca, o tempo de espera do armazenamento permanecer elevado, surgirem erros ou a fila em segundo plano deixar de obter um débito útil crescente. Repita o teste da etapa anterior após um reinício a frio e novamente enquanto o sistema estiver aquecido. Essa etapa inferior e repetível é o limite defensável para esta carga de trabalho.