Porque é que o armazenamento de miniaturas e ML do Immich aumenta durante grandes importações a partir de dispositivos móveis?

As grandes importações normalmente aumentam o armazenamento do Immich porque cada ativo gera derivados e registos na base de dados, enquanto os modelos transferidos ocupam uma cache separada.

Uma família transfere anos de fotografias do telemóvel para um NAS doméstico e depois vê o espaço livre continuar a diminuir quando o contador de carregamento termina. Isso pode refletir processamento legítimo em segundo plano, e não outra cópia de cada original. A distinção útil é entre ficheiros gerados por ativo, ficheiros de modelos partilhados e crescimento que continua sem um aumento correspondente no trabalho concluído.

Um carregamento cria vários tipos de estado

O original carregado é apenas uma parte da biblioteca resultante. O Immich também prepara representações mais pequenas para a navegação e armazena informações que associam o ativo ao proprietário, às datas, aos álbuns e às funcionalidades de pesquisa. Estes resultados servem pedidos diferentes, pelo que concluir a transferência de rede não significa que todas as gravações subsequentes já tenham terminado.

A divisão entre ficheiros multimédia e registos da base de dados é importante neste caso: os metadados da aplicação e os embeddings de pesquisa ficam no PostgreSQL, em vez de serem fotografias adicionais em resolução total. O serviço de aprendizagem automática calcula resultados utilizados pela aplicação. Por isso, tratar todos os bytes adicionais como originais duplicados dá uma explicação errada para o crescimento normal resultante da importação.

Considere um telemóvel que termina a transferência enquanto o servidor continua a processar o lote aceite. Os originais podem já estar estáveis no disco, mas as pré-visualizações e os registos pesquisáveis podem continuar a aparecer. Compare as medições de armazenamento na mesma fase de processamento; um conjunto carregado imediatamente e um conjunto totalmente processado não são amostras equivalentes.

A quantidade de ativos explica mais do que os gigabytes dos originais

Para planear as miniaturas, a quantidade e o tipo de ativos explicam frequentemente mais do que o total de gigabytes dos originais. Mil fotografias pequenas e um punhado de vídeos longos podem ocupar uma capacidade de origem semelhante, mas exigir quantidades muito diferentes de derivados de imagem. As dimensões das pré-visualizações, as definições de compressão e o conteúdo das imagens também alteram os bytes gerados.

Medições publicadas de miniaturas ilustram essa variação: um proprietário indicou 6,3 GB para uma biblioteca de 70 GB, enquanto outro indicou cerca de 370 GB para 2 TB de fotografias e vídeos. São configurações individuais, não testes de referência controlados e comparáveis. Demonstram por que adotar uma percentagem única de um fórum pode representar incorretamente outra família.

Como cálculo ilustrativo, 100 000 ativos com uma média de 250 KB de derivados de imagem medidos requerem cerca de 25 GB em unidades decimais. A 500 KB por ativo, a mesma quantidade necessita de cerca de 50 GB. Nenhum destes valores inclui os originais, vídeos codificados, o crescimento da base de dados ou cópias de segurança; o exemplo isola a relação por ativo, em vez de recomendar uma margem universal.

Os ficheiros de modelos e os registos de pesquisa crescem de forma diferente

A cache de modelos contém ficheiros de modelos reutilizáveis, enquanto os vetores de pesquisa representam ativos individuais. Com um conjunto fixo de modelos transferidos, adicionar mais fotografias não exige transferir um modelo completo novo para cada imagem. Adicionar ou alterar modelos pode, em vez disso, aumentar o armazenamento da cache por etapas, independentemente do número de fotografias carregadas.

Uma implementação portátil real mantém a biblioteca, a cache de modelos e os dados do PostgreSQL em diretórios persistentes separados. Essa separação torna cada função de armazenamento observável, sem pressupor que um único tamanho combinado do Docker represente o resultado da aprendizagem automática. É um exemplo de organização de uma versão mais antiga, não um guia de instalação atual nem um conjunto recomendado de etiquetas de contentores.

Distinga também a utilização do disco da memória carregada. Um modelo pode permanecer no disco enquanto a sua cópia em memória é descarregada, e a cache do sistema de ficheiros pode aumentar a memória reportada sem criar mais ficheiros persistentes. Para explicar um aumento, identifique o diretório responsável e a definição alterada antes de tirar conclusões a partir do nome de um contentor.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quando o crescimento normal deixa de ser uma explicação

O crescimento normal dos derivados tem uma entrada limitada: um conjunto fixo de originais processado com definições fixas. Não deve criar uma população em expansão indefinida de novos ativos de origem. Se a quantidade de ativos continuar a aumentar depois de todas as importações previstas terminarem, a explicação terá de incluir caminhos de descoberta, ingestão repetida ou outra fonte de novo trabalho.

Um caso confirmado de análise recursiva incluía a localização de carregamento do Immich dentro de uma biblioteca externa. As miniaturas geradas eram então tratadas como novas imagens, criando mais derivados de derivados. Este é um mecanismo causal diferente de um grande carregamento móvel e não deve ser utilizado como prova de que todas as bibliotecas grandes se multiplicam naturalmente sem limite.

Um crescimento invulgar na camada gravável de um contentor é outra categoria distinta. Um relatório de 2026 descreveu centenas de gigabytes a acumularem-se nessa camada; a discussão não estabeleceu uma causa-raiz universal. Não elimine bases de dados, ficheiros multimédia ou componentes internos do Docker para fazer um gráfico parecer normal. Primeiro determine qual a função que está a crescer e se o trabalho concluído a explica.

Meça a importação por função de armazenamento

Registe a quantidade e os bytes dos ativos originais, os bytes das miniaturas e pré-visualizações, os bytes dos vídeos codificados, o tamanho da base de dados, o tamanho da cache de modelos e qualquer crescimento temporário ou de registos antes de uma importação representativa. Repita a medição depois de esse mesmo conjunto concluir os trabalhos de processamento ativados. Mantenha as definições multimédia inalteradas para que as diferenças possam ser atribuídas à importação, e não a uma alteração de configuração simultânea.

A contabilização do armazenamento não substitui um plano de cópias de segurança familiar. Um serviço de fotografias utilizável precisa de originais protegidos e do estado da aplicação necessário para reconstruir a biblioteca; um diretório de miniaturas, por si só, não consegue preservar a coleção da família. Mantenha esta tarefa de proteção separada da medição da sobrecarga regenerável, para que uma experiência de poupança de espaço não se transforme na única cópia de uma memória.

Aceite o resultado quando os totais medidos por função explicarem os bytes adicionados e não continuarem a aparecer ativos de origem inesperados. Investigue um mecanismo diferente quando o inventário de modelos permanecer inalterado mas o crescimento da cache ou da camada gravável persistir, ou quando os ficheiros derivados voltarem a entrar na descoberta. Este teste responde à razão pela qual o armazenamento cresceu, sem transformar uma explicação num procedimento de limpeza destrutivo.