관련이없는 몇 가지 사항 :
80K는 많은 파일입니다.
한 디렉토리에 80,000 개의 파일이 있습니까? 기본적으로 운영 체제 또는 앱이 해당 상황을 잘 처리하지 않습니다. rsync 에서이 문제를 발견했습니다.
rsync 버전 확인
최신 rsync는 큰 디렉토리를 과거보다 훨씬 잘 처리합니다. 최신 버전을 사용하고 있는지 확인하십시오.
오래된 rsync조차도 높은 대기 시간 링크를 통해 큰 디렉토리를 상당히 잘 처리하지만 ... 80k 파일은 크지 않습니다 ... 거대한 것입니다!
즉, rsync의 메모리 사용량은 트리의 파일 수에 정비례합니다. 큰 디렉토리는 많은 양의 RAM을 사용합니다. 속도 저하는 양쪽에 RAM이 없기 때문일 수 있습니다. 메모리 사용량을 보면서 테스트를 실행하십시오. Linux는 남은 RAM을 디스크 캐시로 사용하므로 RAM이 부족한 경우 디스크 캐싱이 줄어 듭니다. RAM이 부족하고 시스템이 스왑을 사용하기 시작하면 성능이 실제로 저하됩니다.
--checksum을 사용하고 있지 않은지 확인하십시오
--checksum(또는 -c)는 모든 파일의 모든 블록을 읽을 것을 요구합니다. 아마도 수정 시간 (아이 노드에 저장 됨)을 읽는 기본 동작으로 얻을 수 있습니다.
작업을 작은 배치로 분할하십시오.
Gigasync 와 같은 일부 프로젝트가 있습니다 . "rsync로 전송할 작은 파일 목록을 작성하여 perl을 사용하여 디렉토리 트리를 되풀이 하여 작업량을 늘립니다 ."
여분의 디렉토리 스캔은 많은 양의 오버 헤드가 될 것이지만 아마도 순이익이 될 것입니다.
이 상황에서는 OS 기본값이 설정되어 있지 않습니다.
모든 기본값으로 Linux / FreeBSD / etc를 사용하는 경우 모든 응용 프로그램에서 성능이 저하됩니다. 기본값은 대형 캐시에서 RAM을 낭비하지 않도록 더 작은 디렉토리를 가정합니다.
큰 디렉토리를보다 잘 처리 할 수 있도록 파일 시스템을 조정하십시오. 큰 폴더 크기는 IO 성능을 저하 시킵니까?
"namei 캐시"를보십시오
BSD와 유사한 운영 체제에는 inode ( "namei"캐시)에 대한 이름 조회를 가속화하는 캐시가 있습니다. 각 디렉토리마다 namei 캐시가 있습니다. 너무 작 으면 최적화 이상의 방해가됩니다. rsync가 각 파일에 대해 lstat ()를 수행하기 때문에 80k 파일 각각에 대해 inode에 액세스하게되므로 캐시가 불충분 할 수 있습니다.
다른 파일 시스템을 고려하십시오
XFS는 더 큰 디렉토리를 처리하도록 설계되었습니다. 단일 디렉토리에있는 파일 시스템 다수의 파일 참조
아마도 5 분이 최선일 것입니다.
읽고있는 디스크 블록 수를 계산하고 하드웨어가 해당 블록을 얼마나 빨리 읽을 수 있을지 예상해야합니다.
어쩌면 당신의 기대는 너무 높습니다. 변경된 파일없이 rsync를 수행하기 위해 읽어야하는 디스크 블록 수를 고려하십시오. 각 서버는 디렉토리를 읽고 파일 당 하나의 inode를 읽어야합니다. 80k 파일이 캐시를 날려 버렸기 때문에 아무것도 캐시되지 않았다고 가정 해 봅시다. 수학을 간단하게 유지하기 위해 80k 블록이라고 가정 해 봅시다. 약 40M의 데이터로 몇 초 안에 읽을 수 있습니다. 그러나 각 블록 사이에 디스크 탐색이 필요한 경우 훨씬 오래 걸릴 수 있습니다.
따라서 약 80,000 개의 디스크 블록을 읽어야합니다. 하드 드라이브가 얼마나 빨리 할 수 있습니까? 이것이 긴 선형 읽기가 아닌 임의 I / O임을 고려하면 5 분이 상당히 우수 할 수 있습니다. 1 / (80000 / 600) 또는 7.5ms마다 디스크를 읽습니다. 하드 드라이브 속도가 빠르거나 느립니까? 모델에 따라 다릅니다.
비슷한 것에 대한 벤치 마크
그것에 대해 생각하는 또 다른 방법은 이것입니다. 파일이 변경 ls -Llr되지 않은 경우 동일한 양의 디스크 작업을 수행하지만 파일 데이터를 읽지 않습니다 (메타 데이터 만). ls -Llr실행 시간 은 상한입니다.
rsync (파일을 변경하지 않은 상태)가보다 느리게 실행 ls -Llr됩니까? 그러면 rsync에 사용중인 옵션을 향상시킬 수 있습니다. 아마도 -c디렉토리 나 메타 데이터 (아이 노드 데이터) 이상을 읽는 플래그 나 다른 플래그 일 수 있습니다.
rsync (파일을 변경하지 않은 상태)가 거의 빠른 속도 ls -Llr입니까? 그런 다음 가능한 한 rsync를 조정했습니다. OS 조정, RAM 추가, 더 빠른 드라이브 얻기, 파일 시스템 변경 등을해야합니다.
개발자와 대화
80k 파일은 나쁜 디자인입니다. 그러한 큰 디렉토리를 잘 처리하는 파일 시스템과 시스템 도구는 거의 없습니다. 파일 이름이 abcdefg.txt 인 경우 abdc / abcdefg.txt에 저장하십시오 (반복 참조). 이것은 디렉토리를 더 작은 디렉토리로 나누지 만 코드를 크게 변경할 필요는 없습니다.
또한 ... 데이터베이스 사용을 고려하십시오. 디렉토리에 80k 파일이 있으면 개발자가 실제로 원하는 것이 데이터베이스라는 사실을 해결하고있을 수 있습니다. MariaDB, MySQL 또는 PostgreSQL은 많은 양의 데이터를 저장하는 데 훨씬 더 나은 옵션입니다.
이봐, 5 분 뭐가 문제 야?
마지막으로 5 분이 너무 나빴습니까? 이 백업을 하루에 한 번 실행하면 5 분이 걸리지 않습니다. 예, 나는 속도를 좋아합니다. 그러나 고객에게 5 분이 "충분히 충분"하면 충분합니다. SLA를 작성하지 않은 경우 사용자와의 비공식적 인 논의를 통해 백업 수행 속도를 확인하는 방법에 대해 설명합니다.
성능을 향상시킬 필요가 없다면이 질문을하지 않았다고 가정합니다. 그러나 고객이 5 분만 만족하면 승리를 선언하고 노력이 필요한 다른 프로젝트로 넘어갑니다.
업데이트 : 토론 후 병목 현상이 네트워크라고 판단했습니다. 나는 포기하기 전에 2 가지를 추천 할 것입니다 :-).
- 압축하여 파이프에서 더 많은 대역폭을 짜내십시오. 그러나 압축에는 더 많은 CPU가 필요하므로 CPU에 과부하가 걸리면 성능이 저하 될 수 있습니다. 를 사용하거나 사용하지 않고 rsync를 시도
-z하고 압축을 사용하거나 사용하지 않고 ssh를 구성하십시오. 4 가지 조합 모두 시간을 정하여 이들 중 하나가 다른 것보다 훨씬 더 잘 수행되는지 확인하십시오.
- 네트워크 트래픽을보고 일시 중지가 있는지 확인하십시오. 일시 정지가 있으면 그 원인을 찾아서 최적화 할 수 있습니다. rsync가 항상 전송하는 경우 실제로 제한이 있습니다. 당신의 선택은 :
- 더 빠른 네트워크
- rsync 이외의 것
- 소스와 대상을 더 가깝게 이동하십시오. 그렇게 할 수 없다면, 로컬 컴퓨터와 재 동기화하고 실제 대상과 재 동기화 할 수 있습니까? 초기 rsync 중에 시스템을 종료해야하는 경우이 작업을 수행하면 이점이있을 수 있습니다.