백업 중에 디스크 입출력을 어떻게 제한합니까?


14

나는 기본적으로 밤에 간단한 "tar zcf"를하는 cron을 가지고있다.

서버에는 다음이 있습니다.

  • 8 코어-Intel (R) Xeon (R) CPU E5606 @ 2.13GHz
  • 25GB RAM
  • 우분투 12.04.2 LTS
  • 2 개의 2.728TB 하드 드라이브가있는 하드웨어 RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108)

모니터링 화면 호스트에서 볼 수 있듯이 :

http://clip2net.com/s/57YRKP

타르의 거의 모든 시간 동안 디스크 I / O는> 90 %로 이동하고 다른 모든 앱 (mysql, apache)을 크게 느리게 만듭니다.

두 가지 질문 :

  • 백업 중에 디스크 I / O가 너무 높은 것이 정상입니까?
  • 다른 앱이 계속 올바르게 작동 할 수 있도록 디스크 I / O를 제한하는 방법이 있습니까?

감사합니다!

답변:


11

오히려 일반적인 접근 방식 ionice외에는 (DM) 블록 장치에 대한 대역폭을 정확하게 제어 할 수있는 멋진 장치 매퍼 대상 (ioband)이 있습니다. 불행히도 그것은 표준 커널의 일부가 아닙니다.

또한 타르 속도를 높일 수 있습니다.

  1. 디스크 캐시로 파일 이름 읽기 : find /source/path -printf ""
  2. 디스크 캐시로 inode 읽기 find /source/path -perm 777 -printf ""
  3. 예를 들어 mbuffer 또는 버퍼가있는 파이프를 사용하여 (예 : RAM이 100MiB 이상인) tar를 사용하여 디스크에서 더 큰 블록을 읽고 씁니다. tar ... | mbuffer -m 256M -P 100 -p 1 ...

파일 이름 / 아이 노드를 캐시로 읽어들이는 동안 tar가 수행되는 동안 디스크 IO가 감소하는 이유는 무엇입니까? 평균 IO를 늘리면서 총 시간을 약간만 줄일 것으로 기대합니다.
— scai

3
@scai 이것은 SSD에 도움이되지 않습니다. 내 권장 사항은 회전하는 하드 디스크만을 말합니다. 그로 인해 성능을 저하시키는 것은 머리 움직임입니다. 파일 이름은 연속 블록에 저장되고, inode는 연속 블록에 저장되며, 파일 내용은 연속 블록에 저장됩니다. tar 방식으로 수행하면 한 디렉토리의 파일 (및 하위 디렉토리) 이름을 읽고 한 파일의 inode에 액세스 한 다음 파일 자체, 다음 파일의 inode, 다음 파일 자체에 액세스합니다. 모든 이름과 inode를 차례로 읽는 것보다 더 많은 헤드 이동을 유발합니다.
— Hauke ​​Laging

@scai 성능 영향은 수행 한 작업에 따라 다릅니다. 전체 백업의 경우 크기가 작지만 (파일 크기에 따라 다름) 차등 백업의 경우 큰 차이가 있음을 알았습니다 (타르는 아니지만 사용하지 않기 때문에 이것이 일반적인 영향이어야 함).
— Hauke ​​Laging

내가 올바르게 이해했는지 확인하십시오. 1과 2의 경우 find 명령을 호출하면 Linux가 자동으로 캐시합니까?
— acemtp

@acemtp 맞습니다. find그렇지 않으면 (예를 들어) -perm파일 inode에 액세스하지 않습니다. 그러나 최적화를 통해 두 번의 find호출 을 사용할 수 있습니다 . 동일한 find통화를 두 번 (간격이 거의없는 경우) 두 번째 통화는 일반적으로 몇 초 이내에 완료됩니다 (또는 그 이하). 사용 가능한 메모리 양과 특정 지점에서 캐시 된 데이터 양에 따라 데이터가 캐시에서 제외됩니다. 너무 많이 읽으면 작업 속도가 느려질 수 있습니다. stdin을 통해 파일 이름으로 백업 프로그램에 피드를 제공 할 수 있다면 예를 들어 100 개 파일의 블록을 읽음으로써이를 방지 할 수 있습니다.
— Hauke ​​Laging 13:27에

13

일반적으로 큰 파일이있는 큰 파일 트리에서 만들어 지므로 백업 중에 높은 I / O가 예상됩니다. ionice클래스 및 레벨이있는 ​​Linux에서 I / O 작업의 우선 순위를 지정할 수 있습니다 . IIRC, 클래스 2, 레벨 7은 가장 낮은 비 굶주림 레벨로 다른 I / O로드 및 사용자에게는 실제로 보이지 않습니다. man ionice사용법 및 세부 사항을 참조 하십시오.


1

tar를 버리고 rsync를 사용하는 것이 좋습니다 (Dogsbody에서 언급 한 것처럼). BackupPC를 사용하여 Windows 및 Linux 시스템에서 파일을 백업하고 tar 및 rsync 사용을 지원하며 하드 링크를 자동으로 관리하고 멋진 웹 인터페이스를 제공합니다.

http://backuppc.sourceforge.net/


0

다른 사람들이 대답했듯이, 그렇습니다. 이것은 정상적인 것이며 ionice시스템에 영향을 미치지 않는 좋은 일반적인 방법입니다.

나는 사람들이 tar필요하지 않을 때 일을 여러 번 보았습니다 . 복사하는 데이터의 백분율이 마지막 사본 이후로 변경되지 않은 rsync경우 시도해 보는 것이 좋습니다 .

마지막 사본 이후 변경된 파일 만 복사하여 IO를 줄입니다. 모든 데이터를 계속 읽어야하므로 IO를 절반 이상 줄일 수는 없지만 기록 된 데이터 양을 크게 줄일 수 있습니다 (하드웨어에 따라 작동 속도가 느릴 수 있음).

실행될 때마다 별도의 사본 / 백업을 원할 경우 가장 강력한 옵션 인 –link-dest는 변경되지 않은 파일을 이전 백업으로 하드 링크 할 수 있습니다. 이렇게하면 백업 서버에 엄청난 양의 공간이 절약됩니다. 예를 들어 머신 (Fred)을 백업하고 Fred는 20GB HD를 사용하며 / proc 및 / dev를 제외한 전체 드라이브를 백업 / 복사합니다. 이제 백업 서버에 20GB 디렉토리가 있습니다. 그 다음날 Fred를 다시 백업하고 –link-dest를 어제 백업으로 백업합니다. Rsync는 원격 파일을 로컬 복사본과 비교하며 정확히 동일한 경우 파일 전송을 방해하지 않지만 새 파일을 어제 파일에 하드 링크합니다. 변경된 모든 파일은 최신 파일로 복사되거나 가능한 경우 어제 백업을 사용하여 부분적으로 복사됩니다. 어제 이후로 100MB의 파일 만 변경된 경우 이제 20GB의 파일을 가진 두 개의 디렉토리가 있지만 20 개만 차지합니다.

나는 그것이 당신의 질문에 도움이되고 여전히 대답하기를 바랍니다.

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