2TB (10mil 파일 + dirs)를 이동하면 병목 현상이 무엇입니까?


21

배경

나는 공간이 부족/home/data전송과 필요 /home/data/repo/home/data2.

/home/data/repo1M 개의 디렉토리를 포함하며 각각 11 개의 디렉토리와 10 개의 파일을 포함합니다. 총 2TB입니다.

/home/datadir_index가 활성화 된 ext3에 있습니다. /home/data2ext4에 있습니다. CentOS 6.4 실행

repo/바로 아래에 백만 개의 디렉토리가 있기 때문에 이러한 접근 방식이 느리다고 가정 합니다.


시도 1 : mv빠르지 만 중단됩니다

이것이 완료되면 할 수 있습니다.

/home/data> mv repo ../data2

그러나 1.5TB가 전송 된 후 중단되었습니다. 약 1GB / 분으로 작성되었습니다.

시도 2 : rsync8 시간의 파일 목록 작성 후 크롤링

/home/data> rsync --ignore-existing -rv repo ../data2

'증분 파일 목록'을 작성하는 데 몇 시간이 걸리고 100MB / 분으로 전송됩니다.

더 빠른 접근을 시도하기 위해 취소합니다.

시도 3a : mv불평

하위 디렉토리에서 테스트 :

/home/data/repo> mv -f foobar ../../data2/repo/
mv: inter-device move failed: '(foobar)' to '../../data2/repo/foobar'; unable to remove target: Is a directory

이것이 무엇인지에 대해 잘 모르겠지만 어쩌면 cp나를 구제 할 수 있습니다 ..

시도 3b : cp8 시간이 지나도 아무데도 나타나지 않습니다 .

/home/data> cp -nr repo ../data2

디스크를 8 시간 동안 읽은 후 디스크를 취소하고 rsync로 돌아갑니다.

시도 4 : rsync8 시간의 파일 목록 작성 후 크롤링

/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2

나는 사용 --remove-source-files지금 정리를 시작하면 더 빨리 그것을 만들 수 있습니다 생각.

파일 목록을 작성하는 데 최소 6 시간이 걸리고 100-200MB / 분으로 전송됩니다.

그러나 서버에 하룻밤이 걸리고 연결이 끊어졌습니다.

시도 5 : 이처럼 고통스러운 이유는 300GB입니다.

/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2

다시 중단되었습니다. 은 -W거의 나의 이해 이해가되지해야하는, 더 빨리 "증분 파일 목록을 전송"할 것 같았다. 어쨌든, 전송이 엄청나게 느리고 나는 이것을 포기합니다.

시도 6 : tar

/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)

기본적으로 모든 파일을 다시 복사하려고 시도하지만 기존 파일은 무시합니다. 1.7TB의 기존 파일을 통과해야하지만 적어도 1.2GB / 분으로 읽습니다.

지금까지 이것은 즉각적인 만족감을주는 유일한 명령입니다.

업데이트 : 어떻게 든 nohup으로 다시 중단되었습니다 ..

시도 7 :하라 키리

아직도 이것에 대해 토론

시도 8 : 스크립트로 '병합' mv

대상 디렉토리에는 약 120k 개의 빈 디렉토리가 있으므로 실행했습니다.

/home/data2/repo> find . -type d -empty -exec rmdir {} \;

루비 스크립트 :

SRC  = "/home/data/repo"
DEST = "/home/data2/repo"

`ls #{SRC}  --color=never > lst1.tmp`
`ls #{DEST} --color=never > lst2.tmp`
`diff lst1.tmp lst2.tmp | grep '<' > /home/data/missing.tmp`

t = `cat /home/data/missing.tmp | wc -l`.to_i
puts "Todo: #{t}"

# Manually `mv` each missing directory
File.open('missing.tmp').each do |line|
  dir = line.strip.gsub('< ', '')
  puts `mv #{SRC}/#{dir} #{DEST}/`
end

끝난.


당신은 정확하고 각 디렉토리를 찾아 열거해야하며 1 백만 개의 디렉토리가 고통 스럽습니다.
cybernard

2
밝은면을보십시오. Windows라면 백만 개의 하위 디렉토리를 가질 수없고 여전히 작동하는 OS를 가질 수 있습니다. :)
Jack

1
@Tim, mv다시 한번 왜 안그래 ? 이론적으로 mv대상 파일이 완전히 복사 된 경우에만 소스 파일을 삭제하므로 정상적으로 작동합니다. 또한 머신에 물리적으로 액세스 할 수 ssh있습니까? 아니면 연결을 통해 수행 됩니까?
terdon

5
아뇨. mv용서하지 않습니다. 연결이 끊어지면 데이터를 잃어 버릴 수도 있습니다. 당신이 이것을 끝냈다 고 말했듯이 ssh사용 screen하고 분리 하는 것이 좋습니다 . 로깅을 활성화하고 그런 식으로 추적하십시오. 자세한 정보를 사용하는 경우 시간이 더 오래 걸립니다. 또한 시도iotop
justbrowsing

2
@justbrowsing-잘하셨습니다 screen. 자세한 정보가 궁금하지만 tar지금 다시 시작하기에는 너무 늦었습니다 . 그리고 iotop지난 며칠 동안 내가 가장 좋아하는 유틸리티는 :)
Tim

답변:


6

큰 작업을 작은 작업으로 나누는 것에 대해 들어 보셨습니까?

/ home / data / repo에는 1M 개의 디렉토리가 있으며 각각 11 개의 디렉토리와 10 개의 파일이 있습니다. 총 2TB입니다.

rsync -a /source/1/ /destination/1/
rsync -a /source/2/ /destination/2/
rsync -a /source/3/ /destination/3/
rsync -a /source/4/ /destination/4/
rsync -a /source/5/ /destination/5/
rsync -a /source/6/ /destination/6/
rsync -a /source/7/ /destination/7/
rsync -a /source/8/ /destination/8/
rsync -a /source/9/ /destination/9/
rsync -a /source/10/ /destination/10/
rsync -a /source/11/ /destination/11/

(...)

커피 휴식 시간.


1
나는 막연하게 강조하고있어 이점이 있다는 것입니다 당신이 작은 부품의 진행 상황을 추적 수동으로 일부가 중단되는 경우 (이 단계가 성공적으로 완료 된 알고 있기 때문에) 작업을 재개하는 시간 lesss 걸릴 정도로.
Ярослав Рахматуллин

이것은 기본적으로을 제외하고 결국 끝낸 일입니다 mv. 안타깝게도 도구 회의 mvrsync반 은 없습니다 .
Tim

4

이것은 일어나고 있습니다 :

  • 처음에 rsync는 파일 목록을 작성합니다.
  • 파일 목록의 초기 정렬로 인해이 목록을 작성하는 것이 실제로 느립니다.
  • 이는 ls -f -1을 사용하고 rsync가 사용할 파일 세트를 빌드하기 위해 xargs와 결합하거나 파일 목록이있는 파일로 출력을 경로 재지 정하여 피할 수 있습니다.
  • 이 목록을 폴더 대신 rsync에 전달하면 rsync가 즉시 작동하기 시작합니다.
  • 수백만 개의 파일이있는 폴더에 대한 ls -f -1의 트릭은이 기사에서 완벽하게 설명됩니다. http://unixetc.co.uk/2012/05/20/large-directory-causes-ls-to-hang/

1
rsync와 함께 ls를 사용하는 방법의 예를 들어 줄 수 있습니까? 비슷한 상황은 아니지만 동일합니다. 머신 AI에서 rsyncd가 실행되고 큰 디렉토리 트리를 머신 B로 전송하려고합니다 (실제로 디렉토리의 90 %가 이미 B에 있습니다). 문제는 자주 떨어지는 불안정한 모바일 연결을 사용 하여이 작업을 수행해야한다는 것입니다. 다시 시작할 때마다 파일 목록을 작성하는 데 한 시간을 소비하는 것은 매우 비효율적입니다. 또한 B는 NAT 뒤에 있기 때문에 제어하지 않으므로 A-> B를 연결하기가 어렵고 B-> A는 쉽습니다.
db

@db에 동의하십시오. 예를들 수 있다면이 대답이 훨씬 유용 할 것입니다.
redfox05

1

rsync가 느리더라도 (왜 느려질까요? 어쩌면 -z가 도움이 될 것입니다) 많이 움직 인 것처럼 들리므로 계속 시도해 볼 수 있습니다.

--remove-source-files를 사용한 경우 빈 디렉토리를 제거하여 후속 작업을 수행 할 수 있습니다. --remove-source-files는 모든 파일을 제거하지만 디렉토리는 그대로 둡니다.

그냥 확인 당신이 만든다 하지 마십시오 여러 패스를 할 --delete와 --remove-소스 파일을 사용합니다.

또한 속도를 높이기 위해 --inplace를 사용할 수 있습니다

서버에서 원격으로 수행하려고해서 쫓겨 나면 '스크린'세션 내에서 실행하십시오. 적어도 그렇게하면 실행할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.