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 cresceu e os testes demoraram muito (mais de 2 segundos). Eu pensei em executar os testes em um disco RAM.

Eu executei o teste em /dev/shm . Estranhamente, não correu mais rápido. O tempo médio de execução foi aproximadamente o mesmo que no disco rígido normal. Eu também tentei em um disco RAM baseado em fusível escrito em perl . O site desapareceu, mas eu o encontrei no arquivo da internet . O tempo médio de execução no disco da RAM é ainda mais lento. Talvez por causa da implementação sub-ótima 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 e coleta de resultados e um resumo. O find é um manequim 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 suportado pela memória. É porque o kernel linux manipula o cache do sistema de arquivos de forma tão eficiente que praticamente é um sistema de arquivos suportado pela memória?

    

Answer 1

Em geral, todas as operações acontecem na RAM - os sistemas de arquivos são armazenados em cache. Há exceções a essa regra, mas esses casos bastante especiais geralmente surgem de requisitos bastante específicos. Portanto, até você começar a usar o cache, você não será capaz de dizer a diferença.

Outra coisa é que o desempenho depende muito do sistema de arquivos exato - alguns estão direcionando o acesso a grandes quantidades de arquivos pequenos, alguns são eficientes em transferências de dados em tempo real de e para grandes arquivos (captura / streaming de multimídia), alguns enfatizam a coerência dos dados e outros podem ser projetados para ter um pequeno espaço de memória / código.

De volta ao seu caso de uso: em apenas um ciclo você gera cerca de 20 novos processos, a maioria dos quais apenas cria um diretório / arquivo (note que () cria um sub-shell e find spawns cat para todos os jogos) - o gargalo na verdade não é o sistema de arquivos (e se o seu sistema usa ASLR e você não ter uma boa fonte rápida de entropia, o pool de aleatoriedade do seu sistema também se esgotou muito rápido). 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 meu comentário sobre os testes serem compostos principalmente de pequenas transações.

Carga de trabalho insuficiente para testar

Se você quiser enfatizar o teste do seu sistema de arquivos, precisará de conjuntos maiores de trabalho.

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

Existem várias maneiras de criar um teste que nega os benefícios do sistema e outros fatores que distorcem os resultados do teste.

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