왜이 이상한 시간 행동을 '고양이'했습니까?


8

cat다른 파일을 하나의 큰 파일로 파이프 하는 데 사용 하고 있습니다. 서로 다른 파일의 수는 두 파일에서 최대 10까지 다양하지만 모든 파일의 총 크기는 항상 동일합니다 (2GB).

내 문제 : 총 6 개의 파일이있는 경우에 도달 할 때마다 파일을 연결하는 데 걸리는 시간이 최고치 (즉 5 또는 7보다 크게)이며 이유를 모릅니다.

누구나 아이디어가 있습니까?

파일 (모두 같은 크기)

output
outputTEMP1
outputTEMP2
outputTEMP3
outputTEMP4
outputTEMP5

명령

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

현재 기계는 몇 가지 계산을 수행해야하지만 새 측정을 사용할 수있게되면 나중에 업데이트하겠습니다.


사용중인 정확한 명령 줄은 무엇입니까?
innaM 2009

명령 줄을 추가했습니다.
brandstaetter

확실히 이상하다. 왜 이런 식으로 작동하는지 말할 수는 없지만 일반 텍스트 버그 보고서를 bug-coreutils@gnu.org에 제출해야합니다.
레이놀즈

그것을 측정하십시오! 측정 할 때 캐싱하지 않아야합니다!
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 = 열기, 닫기 로그 열기, 닫기 API. 그것들을 제거하면 매우 시끄러운 로그 파일이 나타납니다.


2

따라서 Davides의 의견이 있습니다. 정확한 평가를 위해서는 두 가지가 필요합니다.

  1. 보증 캐싱은 시나리오의 일부가 아닙니다
  2. 소요 시간의 실제 측정.

디스크 공간이 있다고 가정하면 이것이 실제 문제인지 더 정확하게 판단하는 테스트 시나리오를 설명하겠습니다. 그렇다면,이 접근법의 근거가되는 증거는 개발자가 그 사실을 알고 그것을 재현 할 수 있도록 도와 줄 것입니다.

문제 격리를 돕기 위해 여기서 rm 부분을 수행하지 마십시오. TEMP 파일을 나중에 둘러 보자. 그런 다음 나중에 'rm'부분을 수행하여 테스트를 반복 할 수 있습니다.

테스트 시나리오는 다음과 같습니다.

  • 공간이 없으면 2, 5, 6, 7, 10을 수행하십시오.
  • 각기 다른 디렉토리에 다른 파일을 넣었는지 확인하십시오. 어디서나 중복되지 않음
  • 다음과 같이 시간 명령을 사용하십시오.

    시간 (고양이 출력 TEMP * >> 출력)

실행하는 각 테스트에 대해보고 된 실제, 사용자 및 시스템 번호를 캡처하십시오.

나는 레이놀즈에 동의합니다. 이것이 사실이라면, 반드시 bug-coreutils@gnu.org로 세부 사항을 이메일로 보내주십시오.


또 다른 생각 : 동일한 총량의 데이터를 출력 파일에 복사하고 있는지 확인하십시오. 따라서 총 1GB 인 경우 '2'디렉토리에는 1 / 2GB 크기의 파일이 있고 '10'디렉토리에는 GB 크기의 1/10 크기 인 파일이 있습니다.
pbr
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.