나는 업로드(압축 포함)를 제외하고는 tarball/archived를 실제로 사용한 적이 없습니다. 이제 나는 소프트웨어 프로젝트에 대한 수많은 코딩 실험을 축적했습니다. 기본적으로 집을 백업하거나 다른 장치의 동기화 작업을 할 때 속도가 느려지는 것처럼 보이는 많은 작은 파일(주로 소스 코드 파일 및 git 개체)이 포함된 디렉터리입니다( 저는 주로 USB 케이블을 통해 rsync를 사용합니다.
이것이 문서화된 현상(벤치마크?)인지 궁금합니다. 손대지 않은 긴 프로젝트 디렉토리를 압축하면 작업 속도가 빨라질까요? 이것이 현명한 접근 방식입니까?
ext4 파일 시스템을 사용하고 있습니다.
답변1
오래되고 거의 액세스하지 않는 디렉토리를 tarball에 보관하면 파일 기반 백업 시스템의 성능이 확실히 향상될 수 있습니다.
이것이 문서화된 현상인지 궁금합니다(벤치마크?).
이는 실제로 "로깅 현상"은 아니지만 백업이 필요한지 확인하기 위해 파일 시스템을 검사하고 각 파일을 개별적으로 확인해야 하는 자연스러운 결과입니다.
백업 빈도를 줄일 수 있습니다Faheem Mitha가 제안한대로, 그러나 서로 다른 빈도로 여러 백업을 유지 관리하거나(자주 업데이트되는 콘텐츠 및 이전에 보관된 콘텐츠의 경우) 파일 제외 목록 등을 유지하는 것이 번거로울 수 있습니다. 조만간 이러한 디렉토리에 액세스할 계획이 없다면 패키지로 만드는 것이 매우 좋은 생각이라고 생각합니다. 나는 똑같은 이유로 이것을 여러 번 해왔습니다.
답변2
나는 복제된 저장소의 디렉토리(많은 작은 파일)에서 작은 벤치마크를 실행했습니다.
매개변수는 다음과 같습니다.
17002 files
4.9G
46 root directories
tar command: tar cf (no compression)
rsync command: rsync -aH --delete --stats
결과:
빈 디렉터리에 대한 로컬 rsync(압축 해제된 파일):
real 5m36.447s
user 0m34.692s
sys 0m56.390s
Second local rsync (unpacked files):
real 0m6.810s
user 0m2.257s
sys 0m3.363s
타르 시간:
real 1m14.648s
user 0m14.278s
sys 0m2.175s
빈 디렉터리에 대한 로컬 rsync(압축 해제된 파일):
real 2m6.355s
user 0m20.799s
sys 0m21.122s
빈 디렉터리에 대한 로컬 rsync(패키지 파일):
real 0m0.125s
user 0m0.005s
sys 0m0.011s
따라서 타르 처리를 하면 성능이 크게 향상되는 것으로 보입니다. 놀랍게도 압축 + 두 번째 로컬 rsync는 첫 번째 로컬 rsync보다 총 시간이 덜 걸렸습니다.
또한 Tarring은 무작동 rsync 실행 속도를 크게 향상시킵니다.
압축을 통해 탄화도 시도했습니다. 타르를 바르는 데 gzip10분 정도 걸렸는데 lzop별로 나아지지 않더라고요(7분 정도에 멈췄어요). 아름다운 차트에 따르면http://www.linuxjournal.com/article/8051?page=0,2, 사용하려는 가장 느린 링크가 USB 케이블(약 20MBps)인 경우 압축해도 대역폭이 향상되지 않습니다.
답변3
Rsync는 매번 이러한 모든 파일과 폴더를 확인해야 합니다. 이는 시간, 성능 및 네트워크 로드를 소비합니다. 각 항목을 tarball에 넣으면 수천 개의 검사가 아닌 하나의 파일 검사를 의미합니다. 또한 공간도 절약됩니다.