Contactar o apoio

Respondemos por e-mail, normalmente em dois dias.

Para prevenir abusos, o Google reCAPTCHA verifica este envio; alguns dados são transmitidos ao Google. O script só é carregado na abertura deste formulário.

← Todos os artigos

Um ficheiro de 870 MB num tmpfs e o reinício que se seguiu

A 28 de agosto às 19:35 descomprimi um dia de registo de acessos para /tmp, para dar para ler dois dias de uma vez. Às 19:44 a máquina reiniciou.

o que a máquina tem e o que um ficheiro ocupou 3.794 MB de memória, dos quais /tmp pode levar 1.900 870 MB escritos lá às 19:35 19:35 — um dia de registo descomprimido para /tmp para ler dois 19:44 — o SSH deixa de responder, a página leva 11 s em vez de 0,1 s 19:47 — a máquina está de volta, tempo de funcionamento 0 minutos o MariaDB arranca com crash recovery: o encerramento não foi limpo o journal não sobrevive a um reinício, não se prova — só se data

A propriedade que não foi verificada

Nesta máquina /tmp é um tmpfs. É memória. O df mostra 1,9 GB livres e não diz uma palavra sobre de onde vem esse espaço, e a máquina tem 3.794 MB no total.

Portanto um ficheiro de 870 MB foi parar a um quarto da memória de um servidor pequeno que entretanto servia um sítio e carregava com o teste de outra pessoa. Nove minutos depois o SSH deixou de aceitar ligações, a página respondia em 11 segundos em vez de 0,1, e pouco depois estava de volta, com um tempo de funcionamento de zero minutos.

O que se pode dizer e o que não

O MariaDB arrancou com recuperação de falha, portanto o encerramento não foi limpo. Para além disso, a resposta honesta é que não se consegue demonstrar: o journal desta máquina é volátil e não sobrevive a um reinício, e não existe nenhum kern.log com uma linha de falta de memória. A prova é uma marca temporal nove minutos antes do acontecimento e um ficheiro no sítio errado.

Vale a pena escrevê-lo assim e não como conclusão. «Encheu a memória e o núcleo desistiu» é uma história plausível. Medida não é, e aqui essa diferença pesa mais do que a certeza.

Qual foi o estrago

Nenhum que se tenha conseguido encontrar. O CHECK TABLE nas cinco tabelas mais importantes voltou com OK, as contagens de linhas estavam iguais, a contagem continuava a escrever nesse mesmo dia e as dezasseis tarefas agendadas estavam intactas. A página voltou a responder em 0,14 segundos.

Perdeu-se uma coisa: um processo longo pertencente a outra sessão na mesma máquina. Nada tinha a ver com este trabalho e foi ao fundo com tudo o resto, que é justamente a parte de uma avaria que nenhuma verificação local reporta.

A regra que daí saiu

Os registos aqui andam pelos 700 a 900 MB por dia. Descomprimir um para /tmp significa pôr um quarto da memória da máquina num sítio que parece disco e se comporta como RAM.

Os ficheiros intermédios grandes vão para /var/tmp ou para uma pasta pessoal, ambos no disco. Melhor ainda: não se descomprimem de todo. zcat -f file.gz | awk ... lê em fluxo e não precisa de destino. Todas as medições dos artigos seguintes foram feitas assim.

O que se generaliza

Um sistema de ficheiros indica quanto espaço tem. Não indica de que é feito esse espaço, e as duas perguntas têm respostas diferentes exatamente nos sistemas onde isso mais pesa.

A verificação é uma linha e foi saltada porque o ficheiro era «temporário». Temporário era verdade. Era apenas a propriedade errada em que pensar.

Publicidade