Por que 'gato' tem esse comportamento estranho no tempo?


8

Estou usando catpara canalizar arquivos diferentes em um arquivo grande. O número de arquivos diferentes varia, de dois arquivos a dez, mas o tamanho total de todos os arquivos é sempre o mesmo (alguns GB).

Meu problema: sempre que chego ao caso em que tenho um total de seis arquivos, o tempo necessário para concatenar esses picos (ou seja, significativamente mais do que com cinco ou sete), e não faço ideia do porquê.

Alguém tem uma ideia?

Os arquivos (todos do mesmo tamanho)

output
outputTEMP1
outputTEMP2
outputTEMP3
outputTEMP4
outputTEMP5

Comando

cat outputTEMP* >> output && rm -f outputTEMP*

Atualmente, a máquina precisa executar alguns cálculos, mas atualizarei mais tarde quando novas medições estiverem disponíveis.


Qual é a linha de comando exata que você está usando?
InnaM 04/12/2009

Eu adicionei a linha de comando.
Brandstaetter

Isso é definitivamente estranho. Não sei dizer por que isso funciona dessa maneira, mas talvez você deva enviar um relatório de erro em texto sem formatação para bug-coreutils@gnu.org.
Reynolds

Meça isto! E não se esqueça de não fazer o cache ao medir!
584 Davide

Respostas:


4

Uma maneira de depurar esse problema é usar strace.

strace -tt -e trace=open,close -o /tmp/strace.cat.log cat apt.list authors.txt >/tmp/t.test
cat /tmp/strace.cat.log 

23:12:08.022588 open("apt.list", O_RDONLY|O_LARGEFILE) = 3
23:12:08.023451 close(3)                = 0
23:12:08.023717 open("authors.txt", O_RDONLY|O_LARGEFILE) = 3
23:12:08.025403 close(3)                = 0

A opção -tt registra o registro de data e hora da chamada do sistema na resolução de mili-segundos. -e trace = abrir, fechar o log apenas abrir, fechar a API. Tente removê-los e você verá um arquivo de log muito barulhento.


2

Portanto, o comentário de Davides está no local. Precisamos de duas coisas aqui, para fazer uma avaliação precisa:

  1. cache de garantia não faz parte do cenário
  2. medição real do tempo que está levando.

Supondo que você tenha espaço em disco, descreverei um cenário de teste que determinará com mais precisão se esse é um problema real. Nesse caso, as evidências de suporte dessa abordagem ajudarão os desenvolvedores a saberem que é real e serão capazes de reproduzi-la.

Para ajudar no isolamento de problemas, não vamos fazer a parte rm aqui. deixe os arquivos TEMP pararem depois. Você pode repetir os testes executando a parte 'rm' posteriormente, se desejar.

Aqui está o cenário de teste:

  • crie 9 diretórios - um para cada quantidade de arquivos (2 3 4 5 6 7 8 9 e 10) - se você não tiver espaço, talvez faça apenas 2, 5, 6, 7 e 10.
  • verifique se você está colocando arquivos DIFERENTES em cada um desses diretórios; SEM duplicatas em qualquer lugar
  • use o comando time como este:

    time (saída catTETEMP * >>)

Capture os números reais, de usuário e de sistema relatados para cada teste executado.

Eu concordo com Reynolds; se isso for real, você deve enviar detalhes por e-mail para bug-coreutils@gnu.org.


Outro pensamento: para garantir que você esteja copiando a mesma quantidade TOTAL de dados no arquivo de saída. Portanto, se o total for de 1 GB, no diretório '2' você terá arquivos com 1/2 GB de tamanho e, no diretório '10', você terá arquivos com 1/10 de GB, etc.
pbr
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.