어떻게 이럴 수있어?
cp 또는 rsync(-W --inplace 사용)를 실행하는 데는 93Gb의 경우 2시간이 걸립니다. 전용 백업 네트워크를 통한 테이프 복원에는 41분이 소요됩니다. 테이프 복원 속도는 50Mb/s입니다. 디스크 대 디스크는 최고 16Mb/s로 측정 및 계산되었습니다. CPU가 사용 중이면 2Mb/s입니다.
복원 소프트웨어는 Veritas NetBackup입니다. 디스크는 파이버를 통한 EMC Symmetrix 어레이에 있습니다. 상자는 HP-UX 11i v2를 실행하는 16Gb의 HP rx6600(Itanium)입니다. 모든 디스크는 다음과 같이 하나의 파이버 카드에 있습니다.
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
또한 디스크는 모두 HP LVM 대신 Veritas Volume Manager를 사용하고 있습니다.
업데이트:나에게 이런 생각이 들었다.~ 아니다그냥 디스크에서 디스크로 직접 복사하는 것입니다. 실제로는스냅 사진디스크 사본으로. 스냅샷을 읽으면 속도가 그렇게 느려질 수 있나요? 스냅샷은 HP VxFS 스냅샷(vxsnap 아님)입니다. 아마도 스냅샷과 VxVM 간의 상호 작용으로 인해 속도가 저하되는 것일까요?
업데이트:fstyp -v를 사용하면 블록 크기(f_bsize)가 8192인 것으로 나타납니다. 기본 UNIX 블록 크기는 512(또는 8192/16)입니다. dd로 테스트할 때 블록 크기는 1024k(또는 1048576 또는 8192*128)를 사용했습니다.
블록 크기인지 정말 궁금합니다. 나는 PerlMonks에서 Perl 모듈 File::Copy가 cp보다 빠르다는 것을 읽었습니다. 흥미롭네요. 궁금하네요.
NetBackup이 tar를 사용하는 경우~ 아니다cp:를 사용하면 속도 증가도 설명할 수 있습니다.
업데이트:스냅샷에서 읽는 것은 실제 장치에서 읽는 것보다 거의 두 배 느린 것으로 보입니다. cp 실행은 명령줄에 tar 쓰기와 마찬가지로 느립니다. tar를 사용하는 것이 약간 더 좋지만(파일을 사용할 때) 8GB 파일로 제한됩니다(해당 파일은 96GB 정도입니다). 스냅샷이 아닌 볼륨에 Perl의 File::Copy를 사용하는 것이 가장 빠른 방법 중 하나인 것 같습니다.
나는 그것을 시도할 것이고 내가 얻은 것을 여기에 보고할 것입니다.
답변1
또 다른 질문은 FC 네트워크 내부에 IO 바인딩되어 있는지 여부입니다. SAN 직원에게 다음을 요청하십시오.입증하다(그래프는 좋다)실제사용 가능한 여유 대역폭(아, FC 스위치가 Cisco 스위치인 경우 스위치 내부의 대역폭 문제를 방지하는 방법)
답변2
어레이의 동일한 디스크에서 읽고 쓰는 것이 제한됩니까?
답변3
테이프도 SAN에 있는 경우 xfer가 전달되어 테이프에서 디스크로 바로 이동하는 반면, 복사를 수행하는 호스트를 통해 복사본을 전달해야 하므로 속도가 느려질 수 있습니다.
답변4
디스크가 마더보드의 다른 버스에 연결된 경우 데이터는 3개 이상의 내부 버스를 통해 복사될 수 있으며 대기 시간으로 인해 디스크 간 복사에 대한 IO가 중단됩니다. 이 경우 네트워크 테이프 드라이브가 원본 디스크보다 대상 디스크에 대한 대역폭 경로가 본질적으로 더 높을 가능성이 있습니다.