여기에서 최대 처리량 문제가 발생하여 노브를 조정하는 방법에 대한 조언이 필요합니다. 백업 배포를 위해 10Gbit 파일 서버를 실행 중입니다. LSI MegaRAID 컨트롤러에서 2 개의 디스크 S-ATA2 설정입니다. 서버에는 또한 24gig의 메모리가 있습니다.
처리량을 최대화하여 마지막으로 업로드 한 백업을 미러링해야합니다.
"핫"백업을위한 RAID0은 약 260MB / 초의 쓰기 및 275MB / 초의 읽기를 제공합니다. 크기가 20GB 인 테스트 된 tmpfs는 약 1GB / sec를 제공합니다. 이런 종류의 처리량은 우리가 필요로하는 것입니다.
이제 디스크에 기록하지 않고 (또는 디스크에 기록하고 메모리에 보관하는 것보다) 가장 최근에 업로드 한 파일을 메모리에 가능한 한 오랫동안 캐시하도록 Linux의 가상 메모리 하위 시스템을 어떻게 조정할 수 있습니까?
다음 sysctls를 설정했지만 예상 처리량을 제공하지는 않습니다.
# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000
이것은 해야 이론적으로 I / O를 캐시 우리 16기가바이트을주고 디스크의 쓰기까지 몇 분을 기다립니다. 여전히 서버를 벤치 마크 할 때 쓰기에 영향을 미치지 않으며 처리량은 증가하지 않습니다.
도움이나 조언이 필요합니다.
가능한 빨리 쓰기 시작하는 것이 더 합리적이지 않습니까? 그렇지 않으면 최대 버퍼 크기에 도달하여 갑자기 중지됩니다. 그것이 모두 함께 쓰고 있다면 그것은 당신에게 더 많은 시간을 제공합니다.
—
Zan Lynx
내 응용 프로그램 (기본 Linux + vsftpd)이 4GB (총 24GB)에서 사용하기 때문에 버퍼 전용 20GB 메모리가 있습니다. 백업이 20GB 이하입니다. 백업 실행 후 버퍼에 기록한 다음 디스크에 순차적으로 기록 할 수 있으면 백업 소스 (가상 서버)의 가동 중지 시간이 크게 줄어 듭니다. 추신 : 서버는 문제없이 중단 될 수 있습니다. 복구하는 데 30 분이
—
Peter Meyer
네트워크를 통해 데이터를 전송하는 데 사용하는 응용 프로그램이 디스크와 동기화하는 것처럼 들립니다. 디스크가 유지할 수있는 것보다 빠른 속도로 많은 양의 데이터를 버스트 할 수있는 이유에 대해 의문을 제기하지만 데이터를 캐시에 저장하기 만하면됩니다. 그것은 어딘가에 디자인 결함을 지적합니다.
—
psusi
그것은 결함처럼 들립니다. 백업 솔루션은 서버를 항상 종료하지 않아도됩니다.
—
psusi
@PeterMeyer : RAM이 많더라도 쓰기가 시작될 때까지 기다리는 것은 여전히 실수입니다. 디스크에 들어가기 전에 파일 (임시 파일과 같은)을 편집하거나 삭제하려고하는 경우에만 의미가 있습니다. 백업은 그렇게하지 않습니다. 가능한 빨리 백그라운드 쓰기를 시작하려고합니다. background_ratio를 1 또는 2로 설정하십시오.
—
Zan Lynx