Чому «котяча» така дивна поведінка часу?


8

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

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

Хтось має ідею?

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

output
outputTEMP1
outputTEMP2
outputTEMP3
outputTEMP4
outputTEMP5

Командування

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

Наразі Машині належить виконати деякі розрахунки, але я оновлю пізніше, коли будуть доступні нові вимірювання.


Який саме командний рядок ви використовуєте?
innaM

Я додав командний рядок.
brandstaetter

Це, безумовно, дивно. Я не можу вам сказати, чому це діє так, але, можливо, вам слід подати звичайний текстовий звіт про помилку на bug-coreutils@gnu.org.
Рейнольдс

Виміряйте це! І будьте впевнені, що ви не кешуєте, коли вимірюєте!
Девіде

Відповіді:


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 = відкрити, закрити журнал тільки відкрити, закрити API. Спробуйте видалити їх, і ви побачите дуже шумний файл журналу.


2

Таким чином, коментар Девідса є місцем. Тут нам потрібно дві речі, щоб зробити точну оцінку:

  1. кешування впевненості не є частиною сценарію
  2. фактичне вимірювання часу, який потрібно.

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

Щоб допомогти у вирішенні проблем, давайте взагалі не робитимемо частину rm. нехай файли TEMP потім сидять навколо. Потім ви можете повторити тести, виконуючи частину 'rm' пізніше, якщо бажаєте.

Ось сценарій тестування:

  • зробіть 9 каталогів - по одному на кожну кількість файлів (2 3 4 5 6 7 8 9 і 10) - якщо у вас немає місця, можливо, просто виконайте 2, 5, 6, 7 і 10.
  • переконайтеся, що ви вкладаєте РІЗНІ файли у кожен із цих каталогів; Ніде дублікатів ніде
  • використовуйте команду часу так:

    час (вихід кішкиTEMP * >> вихід)

Зробіть дані про справжні, користувацькі та систематизовані номери, повідомлені для кожного запущеного тесту.

Я згоден з Рейнольдсом; якщо це реально, ви обов'язково надішліть деталі електронною поштою bug-coreutils@gnu.org.


Інша думка: Щоб переконатись, що ви копіюєте ту саму ОБСЯГО кількість даних у вихідний файл. Отже, якщо це загальний обсяг 1 ГБ, у каталозі '2' ви мали б файли розміром 1/2 ГБ, а в каталозі '10' ви мали б файли, що становлять 1/10-ту частину ГБ тощо,
pbr
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.