A eliminação da cache NGINX coloca erros críticos de desvinculação no registo de erros
Publicado: 15 de fevereiro de 2025 às 11:24:41 UTC
Este artigo explica como eliminar itens da cache do NGINX sem que os seus ficheiros de registo fiquem cheios de mensagens de erro. Embora não seja geralmente uma abordagem recomendada, pode ser útil em alguns casos extremos.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
As informações neste post são baseadas na cache FastCGI no NGINX 1.4.6 a correr no Ubuntu Server 14.04 x64. Pode ou não ser válido para outras versões.
(Atualização 2025: No período entre a escrita do post original e agora, muita coisa mudou. Os servidores estão mais rápidos e baratos, por isso não recomendaria a abordagem descrita neste post, onde tento microgerir a expiração da cache apenas para guardar algumas gerações extra de conteúdo dinâmico. Deixarei o conteúdo aqui para referência futura e caso alguém realmente precise dele por qualquer motivo. Não confirmei se isto ainda funciona para as versões atuais do NGINX, mas penso que funciona).
Depois de migrar vários sites do Apache para o NGINX, passei a gostar muito das suas capacidades de cache integradas, que funcionam extremamente bem na maioria das circunstâncias sem grande interferência da minha parte.
No entanto, para um dos sites, precisava realmente da capacidade de limpar a cache (tanto completamente como remover entradas individuais) sozinho. A edição gratuita da comunidade do NGINX suporta apenas a expiração de cache baseada no tempo (ou seja, pode configurá-lo para verificar se algo mudou após uma hora, um dia, etc.). Mas e se não houver uma forma fiável de determinar antecipadamente quando um determinado recurso será alterado? Por exemplo, não faço ideia se vai demorar uma hora, um dia ou um ano até voltar e editar algo neste post. E porquê armazenar em cache apenas durante uma hora se armazenar em cache durante um dia seria bom?
É aqui que é necessária a capacidade de limpar a cache manualmente (ou fazer com que a sua aplicação web notifique o NGINX de que algo deve ser eliminado). As pessoas por trás do NGINX estão claramente cientes da necessidade disto, uma vez que a funcionalidade é suportada na versão paga do produto. No entanto, embora tenham certamente o direito de configurar o licenciamento da forma que quiserem, o preço é um pouco elevado para mim, uma vez que esta função é a única funcionalidade paga de que realmente preciso.
Felizmente, pode simplesmente eliminar ficheiros do diretório de cache e o NGINX irá detetar isso e procurar uma nova cópia do seu back-end sem problemas. No entanto, se o fizer sem ajustar a sua configuração, provavelmente verá um monte de mensagens semelhantes a esta no seu registo de erros passado algum tempo:
Parece que estes erros ocorrem quando o próprio NGINX tenta eliminar as entradas de cache após o tempo especificado pelo parâmetro inativo da diretiva fastcgi_cache_path . O padrão é de apenas 10 minutos, mas pode definir o valor que desejar. Se o definir para, digamos, 10 anos, é improvável que não tenha reiniciado o servidor entretanto, pelo que o índice de chave na memória teria sido limpo entretanto. Se o fizer, terá de limpar o cache sozinho, pois o NGINX já não o fará por si.
Acho muito estranho que seja considerado um erro crítico que uma entrada de cache não possa ser apagada porque não existe. O facto de a sua classificação de gravidade ser tão elevada significa que é impossível livrar-se dela simplesmente ignorando as entradas de registo abaixo de um certo limiar. Assim que uma nova cópia for obtida do back-end, a entrada voltará a existir, pelo que isto deveria ser, no máximo, um aviso, na minha opinião.
Agora, se a entrada de cache não pudesse ser eliminada devido a problemas com permissões ou algo do género, isso seria um erro crítico, porque poderia fazer com que o NGINX continuasse a servir conteúdo em cache muito depois do tempo de expiração, mas o processo de limpeza não parece fazer essa distinção.