por que o script intensivo do sistema de arquivos não é mais rápido no disco RAM

Question

Eu tenho um script que cria muitos arquivos e diretórios. O script faz testes de caixa preta para um programa que funciona com muitos arquivos e diretórios. A contagem de testes aumentou e os testes demoraram muito (mais de 2 segundos). Pensei em executar os testes em um disco RAM.

Fiz o teste em /dev/shm. Estranhamente, ele não correu mais rápido. O tempo médio de execução foi quase o mesmo do disco rígido normal. Eu também tentei em umdisco RAM baseado em fusível escrito em perl. O site desapareceu, mas encontrei-o noarquivo da internet. O tempo médio de execução no disco RAM do fusível é ainda mais lento. Talvez por causa da implementação abaixo do ideal do código Perl.

Aqui está uma versão simplificada do meu script:

#! /bin/sh

preparedir() {
  mkdir foo
  mkdir bar
  touch bar/file
  mkdir bar/baz
  echo qux > bar/baz/file
}

systemundertest() {
  # here is the black box program that i am testing
  # i do not know what it does exactly
  # but it must be reading the files
  # since it behaves differently based on them
  find $1 -type f -execdir cat '{}' \; > /dev/null

singletest() {
  mkdir actual
  (cd actual; preparedir)
  systemundertest actual
  mkdir expected
  (cd expected; preparedir)
  diff -qr actual expected
}

manytests() {
  while read dirname; do
    rm -rf $dirname
    mkdir $dirname
    (cd $dirname; singletest)
  done
}

seq 100 | manytests

O script real faz um pouco mais de verificação de erros, coleta de resultados e um resumo. Este findé um modelo para o programa real que estou testando.

Eu me pergunto por que meu script intensivo de sistema de arquivos não roda mais rápido em um sistema de arquivos com suporte de memória. É porque o kernel do Linux lida com o cache do sistema de arquivos com tanta eficiência que é praticamente um sistema de arquivos com suporte de memória?

Answer 1

De modo geral, todas as operações acontecem primeiro na RAM - os sistemas de arquivos são armazenados em cache. Há exceções a esta regra, mas estes casos bastante especiais geralmente resultam de requisitos bastante específicos. Portanto, até que você comece a liberar o cache, não será capaz de perceber a diferença.

Outra coisa é que o desempenho dependebastanteno sistema de arquivos exato - alguns visam acesso mais fácil a grandes quantidades de arquivos pequenos, alguns são eficientes em transferências de dados em tempo real de e para arquivos grandes (captura/streaming multimídia), alguns enfatizam a coerência de dados e outros podem ser projetados para ter pequena pegada de memória/código.

Voltando ao seu caso de uso: em apenas uma passagem de loop você gera cerca de 20 novos processos, a maioria dos quais apenas cria um diretório/arquivo (observe que ()cria um sub-shell e findgera catpara cada partida) - o gargalo realmente não é o sistema de arquivos (e se o seu sistema usaASLRe você não tem uma boa fonte rápida de entropia, o pool de aleatoriedade do seu sistema também se esgota rapidamente). O mesmo vale para o FUSE escrito em Perl - não é a ferramenta certa para o trabalho.

Answer 2

Uma resposta um pouco mais longa do que o meu comentário sobre os testes serem compostos principalmente por pequenas transações.

Carga de trabalho insuficiente para testar

Se você quiser testar a resistência do seu sistema de arquivos, precisará de conjuntos maiores de trabalho.

Dependendo de quanta memória você tem em sua caixa, mesmo dezenas de milhares de operações de criação de pastas não mostrarão uma diferença perceptível entre as duas. Portanto, modifique sua carga de trabalho para testar suficientemente os sistemas de arquivos, levando em consideração sua memória, que será usada como buffer.

Existem várias maneiras de elaborar um teste que anule os benefícios da memória RAM do sistema e outros fatores que distorcerão os resultados do teste.

Ou você pode usar um conjunto de testes padronizado, como bonnie++