tempo de acesso ao arquivo após carregar o arquivo no cache

Question

Eu li de aqui que eu poderia carregar o arquivo na RAM para acesso mais rápido usando o comando abaixo.

cat filename > /dev/null

No entanto, eu queria testar se a afirmação acima é realmente verdadeira. Então, eu fiz o teste abaixo.

1. Crie um arquivo de teste de 2,5 GB como abaixo.

   dd if=/dev/zero of=demo.txt bs=100M count=10
   

2. Agora, calculamos o tempo de acesso ao arquivo, conforme abaixo.

   mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
   echo $mytime
   real 0m19.191s user 0m0.007s sys 0m1.295s
   

3. Conforme o comando sugere, agora eu precisava adicionar o arquivo ao cache memória. Então, eu fiz,

   cat demo.txt > /dev/null
   

4. Agora, presumo que o arquivo esteja carregado no cache. Então eu calculo o hora de carregar o arquivo novamente. Este é o valor que recebo.

   mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
   echo $mytime
   real 0m18.701s user 0m0.010s sys 0m1.275s
   

5. Repeti o passo 4 para mais 5 iterações para calcular o tempo e estes são os valores que eu tenho.

   real 0m18.574s user 0m0.007s sys 0m1.279s
   real 0m18.584s user 0m0.012s sys 0m1.267s
   real 0m19.017s user 0m0.009s sys 0m1.268s
   real 0m18.533s user 0m0.012s sys 0m1.263s
   real 0m18.757s user 0m0.005s sys 0m1.274s
   

Então, minha pergunta é: por que o tempo varia mesmo quando o arquivo é carregado no cache? Eu estava esperando desde que o arquivo é carregado no cache, o tempo deve descer em cada iteração, mas isso não parece ser o caso.

    

Answer 1

Não, não, não!

Não é assim que é feito. O Linux (o kernel) pode optar por colocar alguns arquivos no cache e removê-los sempre que quiser. Você realmente não pode ter certeza de que alguma coisa está no cache ou não. E esse comando não vai mudar isso (muito).

O conselho no link que você forneceu é tão errado de muitas maneiras!

1. O cache é uma coisa do sistema operacional. Você não precisa cat do arquivo para /dev/null para aproveitar isso. Esta é realmente uma coisa muito estúpida, porque você está forçando o Linux a ler o arquivo uma vez. Por exemplo, se você planeja ler um arquivo 4 vezes. Se você não se importar com isso, a primeira leitura será bem lenta, os 3 subsequentes deverão ser mais rápidos (por causa do cache). Se você estiver usando esse "truque", a primeira leitura será bem lenta, todos os 4 subsequentes deverão ser mais rápidos (mas não nulos). Apenas deixe o Linux lidar com ele .
2. Este comando só é útil se você quiser ter certeza de que o Linux o mantém na RAM. Então você tem que executá-lo muitas vezes quando o sistema está ocioso. No entanto, como eu disse, isso também é estúpido porque você nunca pode ter certeza de que o Linux realmente armazenou o arquivo em cache na RAM e, mesmo se o fizesse, gastaria tempo para lê-lo na RAM ou no disco (se não estivesse armazenado em cache ou já removido do cache).
3. Ao fazer isso repetidamente em um arquivo grande, você basicamente faz o Linux pensar que esse arquivo deve estar na RAM às custas de outros arquivos que você realmente usa com mais frequência.

Portanto, a conclusão aqui: não faça esse tipo de truques, isso geralmente é contraproducente.

No entanto, , se você sabe que alguns arquivos pequenos (comparados ao tamanho da sua RAM) realmente se beneficiariam do acesso da RAM, você pode usar um tmpfs mount e armazene seu arquivo lá. Em distribuições modernas, a pasta /tmp geralmente é um tmpfs one.

Outra alternativa que eu pessoalmente achei digna é comprimir o seu arquivo no nível do FS com o BTRFS, por exemplo, ou manualmente (mas este requer que o programa que acessa o arquivo tenha a capacidade de descompactá-lo). Naturalmente, seus arquivos devem se beneficiar da compactação, caso contrário, isso é inútil. Dessa forma, você pode estar muito mais confiante de que o Linux mantém seu arquivo compactado na RAM (já que é menor) e se seu aplicativo for IO ligado, carregar 100 MB do disco em vez de carregar 10 GB deve ser muito mais rápido.