☰

많은 파일에 대한 tar -xf 성능

tag-icon • tag-icon tar
많은 파일에 대한 tar -xf 성능

상당히 작은 파일이 많이(수천 개) 들어 있는 디렉토리를 타르볼에 저장하는 방법에는 두 가지가 있습니다:

  1. 모든 파일을 roottarball 에 저장
  2. 디렉토리 자체를 tarball에 저장하고 파일을 디렉토리 내에 저장하십시오.

이것이 tar의 압축 해제 속도( )에 성능에 영향을 미치나요 tar -xf?

나는 두 번째 접근 방식이 더 빠를 것이라고 상상할 수 있지만(아마도 더 빠를 것입니다) tar가 어떻게 작동하는지 정확히 알지 못하므로 질문입니다.

논평:

  • Wrap()에 대해서도 같은 질문을 할 수 있지만 tar -cf나에게는 덜 중요합니다.
  • 물론 몇 가지 테스트를 직접 실행할 수도 있지만 실제로 더 빠르다면 이론적인 설명이 필요합니다.

답변1

이론적 답변은 아니지만 테스트해 볼까 생각했습니다. 저는 FreeBSD 10.3을 실행하는 Dell 1955 블레이드를 가지고 있습니다. 따라서 이는 bsdtar에만 해당될 수 있습니다. 두 개의 ZFS 파일 시스템을 만들어 별도로( /zroot/tar1및 ) 유지 /zroot/tar2한 다음 다음을 사용하여 임의의 콘텐츠가 포함된 4000개의 1MB 파일을 생성했습니다.

for i in {1..4000}; do
    dd if=/dev/urandom of=/zroot/tar1/tar_test.$i bs=1M count=1
done

그런 다음 이 4000개의 파일을 "mytar"가 있는 디렉터리에 복사했습니다 /zroot/tar2/mytar(따라서 매번 정확히 동일한 데이터를 사용합니다).

먼저 모든 "느슨한" 파일이 있는 파일 시스템에서 해당 파일을 모두 보관한 다음 삭제하고(tar 파일만 남겨두고) 보관을 취소했습니다. 나는 다음과 같이 이 작업을 5번 수행했습니다.

tar cf 1.tar *  0.76s user 16.98s system 6% cpu 4:52.68 total
tar cf 1.tar *  0.74s user 16.51s system 5% cpu 4:51.63 total
tar cf 1.tar *  0.94s user 16.19s system 5% cpu 4:55.50 total
tar cf 1.tar *  0.82s user 16.15s system 5% cpu 4:52.72 total
tar cf 1.tar *  0.69s user 16.22s system 5% cpu 4:52.00 total

tar xf 1.tar  0.44s user 10.52s system 3% cpu 4:54.92 total
tar xf 1.tar  0.39s user 10.67s system 3% cpu 5:03.59 total
tar xf 1.tar  0.39s user 10.51s system 3% cpu 4:52.85 total
tar xf 1.tar  0.46s user 10.45s system 3% cpu 5:01.28 total
tar xf 1.tar  0.44s user 10.59s system 3% cpu 5:01.29 total

마지막 추출 후 tar 파일을 삭제하고 /zroot/tar2동일한 테스트를 다시 수행하기 위해 위치를 변경했습니다. 이번에는 동일한 4000개 파일이 포함된 디렉터리에서만 수행되었습니다.

tar cf 2.tar mytar  0.72s user 16.51s system 5% cpu 5:25.84 total
tar cf 2.tar mytar  0.61s user 16.19s system 5% cpu 5:18.19 total
tar cf 2.tar mytar  0.68s user 16.14s system 5% cpu 5:01.50 total
tar cf 2.tar mytar  0.65s user 15.87s system 5% cpu 4:41.64 total
tar cf 2.tar mytar  0.68s user 16.71s system 5% cpu 5:07.72 total

tar xf 2.tar  0.42s user 10.39s system 3% cpu 4:57.50 total
tar xf 2.tar  0.41s user 10.41s system 3% cpu 4:50.07 total
tar xf 2.tar  0.47s user 10.26s system 3% cpu 4:57.25 total
tar xf 2.tar  0.58s user 10.50s system 3% cpu 5:00.45 total
tar xf 2.tar  0.40s user 11.34s system 4% cpu 4:50.24 total

평균 시간을 계산하면 다음과 같은 결과를 얻습니다.

+===========+=========+===========+
|           |  Loose  | Directory |
+===========+=========+===========+
| Archive   | 4:52.91 | 5:06.97   |
+-----------+---------+-----------+
| Unarchive | 4:58.79 | 4:55.1    |
+-----------+---------+-----------+

따라서 디렉터리를 사용하면 파일 보관 취소가 약간 향상되지만 초기 보관에 대한 페널티가 약간 더 높다는 것을 알 수 있습니다.

나는 동일한 작업을 다시 수행했지만 truss를 사용하여 각 작업의 요약을 얻었고 평균적으로 시스템 호출에 소요된 총 시간을 얻었습니다.

+===========+=======+===========+
|           | Loose | Directory |
+===========+=======+===========+
| Archive   | 04:43 | 04:58     |
+-----------+-------+-----------+
| Unarchive | 04:56 | 04:50     |
+-----------+-------+-----------+

read() 시스템 호출에 소요된 가장 많은 시간(역시 평균):

+===========+=======+===========+
|           | Loose | Directory |
+===========+=======+===========+
| Archive   | 03:53 | 04:07     |
+-----------+-------+-----------+
| Unarchive | 04:37 | 04:36     |
+-----------+-------+-----------+

보관 취소 시 가장 큰 이점은 더 빠른 read() 호출과 더 빠른 lstat() 호출의 조합에서 비롯됩니다(lstat는 stat와 비슷하지만 파일이 심볼릭 링크인 경우 추적되지 않고 대신 관련 심볼릭 링크 정보를 반환합니다).

평균 lstat() 횟수는 다음과 같습니다.

+-------+-------+-----------+
|       | Loose | Directory |
+-------+-------+-----------+
| lstat |  8.57 |      0.97 |
+-------+-------+-----------+

이것이 당신에게 도움이 될지 확신할 수 없습니다. 하지만 귀하의 질문에 관심을 갖고 조사를 한 후에 제가 본 내용을 공유하고 누군가가 더 자세히 조사할 수 있는지 알아보고 싶다고 생각했습니다.

다음은 각 실행에 대한 요약 파일에 대한 링크입니다., 그들은 관심을 가져야 합니다.

전체 추적의 크기(~50MB)로 인해 온라인 영구 위치(paste2.org/pastebin/etc)에 업로드하는 데 어려움이 있습니다.

답변2

이는 주로 사용 중인 파일 시스템에 따라 다릅니다. 특정 이름의 디렉터리 항목이 있는지 확인하기 위해 O(n) 조회가 필요한 ext2 및 기타 이전 파일 시스템에서는 플랫 디렉터리가 느려질 수 있습니다. ext3/4 및 기타 최신 파일 시스템은 더 큰 디렉터리에 대해 트리 기반 인덱스를 사용하므로 O(log n) 조회 시간만 필요합니다.

패키징(tar -cf)에 대해서도 동일한 질문을 할 수 있지만 나에게는 덜 중요합니다.

반면에 Tar 생성은 디스크 IO와 구현이 미리 읽기를 수행하는지 여부에 크게 좌우됩니다. 작은 파일은 무작위 읽기를 많이 생성하며 단일 파일 미리 읽기는 작은 파일에 대해 작동하지 않습니다. 나는 이미 썼다파스타이 사용 사례에 대한 특수 구현으로 파일을 읽는 순서를 최적화하고 여러 파일에 대해 미리 읽기를 수행하는 것이 가능합니다.

답변3

추출 시간의 차이는 추출에 필요한 총 시간에 비해 적어도 규모(수천 개의 파일)에서는 크지 않습니다. tar 형식은 매우 간단합니다. 기본적으로 헤더와 파일, 헤더와 파일을 연결합니다. 따라서 추출할 때 tar는 데이터의 압축을 해제합니다. 특히 기존 파일을 덮어쓰는 것에 신경쓰지 않기 때문에 확인 시간을 낭비하지 않습니다. (절대 경로가 있는 타르볼은 약간 다르게 처리되지만 이는 어쨌든 나쁜 타르 관행입니다).

관련 정보