일반화하다
네트워크를 통해 전송할 데이터가 없을 때 데이터를 읽은 다음 로컬 디스크/파일 시스템에서 데이터를 동시에 읽고 네트워크 공유에 쓰도록 Linux를 구성하는 방법 유휴 상태야?
동시에 읽고 쓰는 것은 한 작업을 수행한 다음 다른 작업을 교대로 수행하는 것보다 훨씬 빠릅니다.
세부 사항
Linux 시스템의 로컬 디스크에서 NAS 장치로 대량의 데이터를 이동하고 있습니다.
저는 기본적으로 CIFS 마운트 에 rsync복사 하곤 했습니다 ./srv/data/mnt/nas
처음에는 읽기와 쓰기가 동시에 가능한 100MB/초의 읽기 속도와 100MB/초(기가비트 네트워크의 한계)로 NAS에 쓰는 성능이 좋았습니다.
하지만 몇 시간이 지난 지금, 로컬 디스크에서 읽고 있는 것을 발견했습니다. 그런 다음 NAS에 쓸 때 읽기를 중지하고, NAS에 쓸 데이터가 더 이상 없으면 디스크에서 읽기를 다시 시작합니다. 다시. 디스크를 읽는 중에는 네트워크가 유휴 상태이고, 네트워크를 사용하는 중에는 디스크가 유휴 상태입니다.
말할 필요도 없이 200MB를 읽고 200MB를 쓰는 것은 200MB를 동시에 읽고 쓰는 것보다 훨씬 오래 걸립니다.
읽기와 쓰기를 번갈아 가며 한 번에 하나의 작업을 수행하는 대신 동시에 읽고 쓰는 초기 동작을 고수하도록 커널을 구성하려면 어떻게 해야 합니까?
몇 가지 관찰 사항: 로컬 디스크가 100+MB/초의 속도로 읽을 때 모든 것이 병렬로 잘 진행되는 것처럼 보이지만 디스크 속도가 느려지면(어떤 이유로 현재는 20MB/초에 불과한 것으로 보임) 전환이 발생하는 것 같습니다. 읽거나 쓸 때 발생합니다.
쓰기가 읽기와 병렬로 발생하도록 몇 초마다 수동으로 실행할 수도 있지만 sync(분명히 속도는 느려지지만) 5초마다 실행되도록 sync루프를 넣는 것은 올바른 솔루션처럼 보이지 않습니다. while... .
커널은 약 1GB의 데이터를 캐시한 다음 가능한 한 빨리 네트워크를 통해 기록하는 것 같습니다. 괜찮습니다. 데이터가 전송되는 동안 느린 디스크에서 읽기를 중지해야 하는 이유를 이해할 수 없습니다. 네트워크.
답변1
더 자세히 조사한 결과 이 문제는 커널과의 관련성보다는 rsyncCIFS의 상호 작용 방식과 더 관련이 있는 것으로 보입니다.
내가 알 수 있는 한, rsync대상 파일이 닫히면 CIFS(및 아마도 모든 네트워크 파일 시스템)는 close시스템 호출이 반환되기 전에 파일이 완전히 플러시되고 원격 디스크에 기록되도록 보장합니다. 이는 종료 작업이 성공적으로 완료되면 파일이 완전히 저장되었으며 데이터 손실을 초래할 수 있는 추가 오류가 발생할 위험이 없다는 확신을 모든 응용 프로그램에 제공하기 위한 것입니다.
이 작업이 수행되지 않으면 응용 프로그램이 파일을 닫고 저장 작업이 성공했다고 생각하여 종료한 다음 (아마도 네트워크 문제로 인해) 데이터가 기록되지 않게 되지만 그때는 응용 프로그램에 너무 늦을 것입니다. 사용자에게 파일을 다른 곳에 저장할 것인지 묻는 등의 조치를 늦게 취합니다.
이 요구 사항은 파일을 복사할 때마다 다음 파일을 읽기 rsync전에 네트워크를 통해 전체 디스크 버퍼를 지워야 함을 의미합니다.rsync
해결 방법은 이 기능을 비활성화하는 옵션을 사용하여 CIFS 공유를 마운트 cache=none하고 모든 I/O가 서버로 직접 이동하도록 하는 것입니다. 이렇게 하면 문제가 제거되고 읽기 및 쓰기가 병렬로 실행될 수 있지만 이 솔루션의 단점은 성능이 약간 낮다는 것입니다. 제 경우에는 네트워크 전송 속도가 110MB/초에서 80MB/초로 떨어졌습니다.
이는 대용량 파일을 복사하는 경우 읽기/쓰기 동작을 번갈아 수행하면 성능이 더 좋아질 수 있음을 의미할 수 있습니다. 많은 작은 파일의 경우 캐싱을 비활성화하면 파일을 닫을 때마다 캐시 플러시 횟수가 줄어들어 성능이 향상될 수 있습니다.
rsync마지막 파일이 플러시되는 동안 다음 파일 읽기를 시작할 수 있도록 다른 스레드에서 파일 핸들을 닫는 옵션이 필요한 것 같습니다 .
편집하다:cache=none작은 파일을 많이 전송할 때(10MB/초에서 80MB/초로 증가) 확실히 도움이 되지만, 대용량 파일(1GB 이상)을 전송할 때 cache=none전송 속도가 110MB/초에서 동일한 80MB/초로 떨어지는 것을 확인했습니다 . . 이는 많은 작은 파일의 느린 전송이 소스 디스크 조회와 관련이 적고 모든 작은 파일의 대용량 캐시 플러시와 더 관련이 있음을 나타냅니다.