Porque é que a ARC do ZFS diminui quando a IA local utiliza memória do anfitrião fixada?
O ZFS ARC diminui durante a utilização de memória do anfitrião fixada porque os buffers de transferência de IA não recuperáveis aumentam a pressão sobre a memória que o kernel pode recuperar, incluindo a cache do sistema de ficheiros.
Os runtimes de GPU fixam páginas do anfitrião para que os dispositivos possam transferir dados sem que essas páginas sejam movidas ou trocadas durante a operação. Isto melhora a previsibilidade do DMA, mas as alocações fixadas são alvos pouco adequados para recuperação quando a RAM disponível diminui. O Linux invoca mecanismos de recuperação e de redução, e o ZFS responde expulsando blocos em cache ou reduzindo o seu objetivo de ARC, deixando mais memória para alocações que não podem ceder.
As páginas fixadas alteram a memória que o kernel pode recuperar
As páginas anónimas comuns podem ser trocadas, e as páginas limpas da cache de ficheiros podem ser descartadas. As páginas fixadas a longo prazo permanecem residentes porque um dispositivo ou controlador depende do seu mapeamento físico, reduzindo o conjunto flexível disponível para satisfazer novas alocações.
A documentação do Linux sobre fixação de páginas a longo prazo distingue a fixação de páginas a longo prazo das referências comuns e explica por que motivo os utilizadores de DMA têm de marcar as páginas corretamente. O mecanismo torna a memória fixada qualitativamente diferente de uma alocação de processo que o kernel pode mover ou recuperar facilmente.
As estruturas de IA utilizam buffers de preparação fixados para cópias mais rápidas do anfitrião para o dispositivo, filas de carregamento de dados e descarga. Vários trabalhadores ou filas de pré-obtenção sobredimensionadas podem manter muito mais memória do anfitrião fixada do que um único lote visível sugere. Esta distinção continua visível durante os testes domésticos posteriores.
O ARC é, por conceção, um grande consumidor recuperável
A Cache de Substituição Adaptativa retém blocos ZFS utilizados recentemente e com frequência para evitar leituras do armazenamento. No Linux, participa no tratamento da pressão de memória e pode reduzir o seu tamanho residente quando o sistema precisa de páginas noutro local. O resultado intermédio tem de permanecer inspecionável antes de a automatização avançar.
A documentação do OpenZFS sobre tamanho e recuperação do ARC descreve os controlos do tamanho do ARC e os parâmetros ajustáveis relacionados com a recuperação. Um máximo configurado é um limite superior, não uma promessa de que os dados em cache permanecerão residentes sob pressão. Esse limite deve ser medido separadamente em condições de funcionamento realistas.
Quando os buffers fixados aumentam, a expulsão do ARC pode ser a resposta correta, e não uma fuga. A consequência surge mais tarde sob a forma de rácios de acertos da cache mais baixos, mais leituras do disco e acesso mais lento aos ficheiros depois de o trabalho de IA terminar, até a cache aquecer novamente.
A memória unificada e as métricas dos contentores podem ocultar a concorrência
Numa GPU integrada, os tensores do modelo e a cache do sistema de ficheiros utilizam a mesma RAM física, mesmo quando os painéis apresentam a utilização de forma diferente. Numa GPU dedicada, a preparação no anfitrião continua separada da VRAM, mas ainda concorre com o ARC no servidor.
A implementação do redutor ARC do OpenZFS para Linux regista o comportamento de recuperação do ARC na gestão de memória do kernel. As evidências ao nível do código ajudam a distinguir a redução deliberada da cache de uma aplicação que ordena diretamente ao ZFS que descarte blocos. A consequência prática surge quando várias fontes competem por um contexto limitado.
O limite de falha consiste em assumir memória fixada sempre que o ARC diminui. Uma leitura extensa de ficheiros, limites explícitos do ARC, pressão de metadados, recuperação por cgroup, crescimento de máquinas virtuais ou o comportamento adaptativo normal podem produzir o mesmo gráfico. Confirme as contagens de páginas fixadas e o momento das alocações.
Correlacione os bytes fixados com a recuperação do ARC e os erros da cache
Execute uma carga de trabalho de IA fixa enquanto regista a memória fixada ou não expulsável, MemAvailable, bloqueios de recuperação, tamanho e objetivo do ARC, rácio de acertos do ARC, leituras do ZFS, tamanho do conjunto de buffers fixados, número de trabalhadores, tamanho do lote, VRAM e latência dos pedidos. Inclua uma linha de base de armazenamento sem IA.
Utilize a memória partilhada do anfitrião para separar os sintomas do CPU, da memória e do armazenamento. Repita com transferências pagináveis, menor profundidade de pré-obtenção, menos trabalhadores e um conjunto limitado de buffers fixados, alterando apenas um controlo por execução. Esta dependência deve permanecer explícita na interface final.
Considere a fixação causal quando a contração do ARC acompanhar o crescimento da memória fixada e diminuir com um conjunto mais pequeno. Limite o conjunto se os erros de cache do armazenamento prejudicarem outros serviços, mas mantenha fixação suficiente para evitar privar o acelerador de recursos; o equilíbrio correto depende da procura concorrente do NAS.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Porque é que as alterações de ficheiros SMB chegam a um indexador incremental em rajadas?
Veja como o armazenamento em cache de escrita SMB, as concessões, CHANGE_NOTIFY, o transbordamento do buffer, a reconexão e o processamento em lotes do...
Porque é que o OCR não deteta texto ténue depois de um PDF ser recomprimido?
Saiba como a recompressão de PDF altera pixels ténues, por que razão os visualizadores podem ocultar essa perda e como testar a resolução, o...
Porque é que a latência da IA local oscila com a curva da ventoinha de um servidor doméstico?
Veja como o calor, o controlo da ventoinha, os limites do relógio, o atraso dos sensores e o timing da carga de trabalho criam...
