Почему «кошка» так странно ведет себя во времени?


8

я использую cat передать разные файлы в один большой файл. Количество разных файлов варьируется от двух до десяти, но общий размер всех файлов всегда одинаков (пара ГБ).

Моя проблема: каждый раз, когда у меня есть шесть файлов, время, необходимое для их объединения пики (то есть значительно больше, чем с пятью или семью), и я понятия не имею, почему.

У кого-нибудь есть идея?

Файлы (все одинакового размера)

output
outputTEMP1
outputTEMP2
outputTEMP3
outputTEMP4
outputTEMP5

команда

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

В настоящее время машина должна выполнить некоторые вычисления, но я обновлю ее позже, когда появятся новые измерения.


Какую именно командную строку вы используете?
innaM

Я добавил командную строку.
brandstaetter

Это определенно странно. Я не могу сказать вам, почему это так, но, возможно, вам следует отправить отчет об ошибке в виде простого текста на bug-coreutils@gnu.org.
Reynolds

Измерь это! И будьте уверены, что вы не кешируете при измерении!
Davide

Ответы:


4

Одним из способов устранения этой проблемы является использование 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

Опция -tt записывает метку времени системного вызова с разрешением в миллисекунды. -e trace = open, закрывать только журнал, закрывать API. Попробуйте удалить их, и вы увидите очень шумный файл журнала.


2

Таким образом, комментарий Дэвидеса точный. Нам нужны две вещи, чтобы сделать точную оценку:

  1. уверенное кэширование не является частью сценария
  2. фактическое измерение времени, которое требуется.

Предполагая, что у вас есть место на диске, я опишу тестовый сценарий, который более точно определит, является ли это реальной проблемой. Если это так, подтверждающие данные этого подхода помогут разработчикам узнать, что это реально, и смогут воспроизвести его.

Чтобы помочь с изоляцией проблемы, давайте не будем делать здесь часть rm. Позвольте файлам TEMP сидеть без дела позже. Затем вы можете повторить тесты, выполнив часть 'rm' позже, если хотите.

Вот тестовый сценарий:

  • создайте 9 каталогов - по одному на каждое количество файлов (2 3 4 5 6 7 8 9 и 10) - если у вас нет места, возможно, просто выполните 2, 5, 6, 7 и 10
  • убедитесь, что вы помещаете РАЗНЫЕ файлы в каждый из этих каталогов; НЕТ дубликатов в любом месте
  • используйте команду времени следующим образом:

    время (cat outputTEMP * & gt; output)

Захватите реальные, пользовательские и системные значения, указанные для каждого теста, который вы запускаете.

Я согласен с Рейнольдсом; если это действительно так, вы обязательно должны отправить подробности по электронной почте bug-coreutils@gnu.org.


Еще одна мысль: чтобы убедиться, что вы копируете тот же ОБЩИЙ объем данных в выходной файл. Таким образом, если общий объем составляет 1 ГБ, в каталоге «2» будут находиться файлы размером 1/2 ГБ, а в каталоге «10» - файлы размером 1/10 ГБ и т. Д.
pbr
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.