많은 수정 후 SVN 성능

Question

내 프로젝트는 현재 하루에 수백 개의 새로운 개정을 얻는 SVN 저장소를 사용하고 있습니다. 이 저장소는 Win2k3-Server에 상주하며 Apache/Mod_dav_svn을 통해 제공됩니다.

나는 시간이 지남에 따라 너무 많은 수정으로 인해 성능이 저하 될까봐 두려워합니다.
이 두려움이 합리적입니까?
우리는 이미 1.5로 업그레이드 할 계획이므로 하나의 디렉토리에 수천 개의 파일이 장기적으로 문제가되지 않습니다.

2 개의 개정 사이의 델타 (차이) 저장은 저장하므로, 특히 코드 (텍스트) 만 커밋하고 바이너리 (이미지 및 문서) 만 커밋하는 경우 많은 공간을 절약하는 데 도움이됩니다.

Foo.baz 파일의 개정 10을 확인하기 위해 SVN은 개정 1을 가져간 다음 Deltas 2-10을 적용한다는 것을 의미합니까?

Answer 1

어떤 유형의 리포가 있습니까? FSFS 또는 BDB?

(지금은 FSF를 가정 해 봅시다. 그것이 기본값이기 때문입니다.)

FSFS의 경우 각 개정은 이전과의 차이로 저장됩니다. 따라서 많은 수정 후에는 매우 느릴 것이라고 생각할 것입니다.

그러나 이것은 사실이 아닙니다. FSFS는 이전 Revs에서 너무 많은 조회를하지 않도록 "Skip Deltas"라고하는 것을 사용합니다.

(따라서 FSFS Repo를 사용하는 경우 Brad Wilson의 답변이 잘못되었습니다.)

BDB 리포지토리의 경우 헤드 (최신) 개정은 전체 텍스트이지만 이전 개정판은 헤드에 대한 일련의 차이로 구축되었습니다. 이는 각 커밋 후 이전 Rev가 다시 계산되어야한다는 것을 의미합니다.

더 많은 정보를 위해서: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

추신 : 우리의 리포지토리는 약 20GB이며 약 35,000 개 수정으로 성능 저하를 보지 못했습니다.

Answer 2

Subversion은 가장 최신 버전을 전체 텍스트로 저장하고 뒤로 보이는 차이가 있습니다. 이것은 헤드에 대한 업데이트가 항상 빠르며, 당신이 점진적으로 지불하는 것은 역사상 더 멀리 떨어져있는 것입니다.

Answer 3

나는 개인적으로 실제 프로젝트를 위해 80k LOC보다 큰 코드베이스가있는 Subversion 리포지토리를 다루지 않았습니다. 내가 실제로 가진 가장 큰 저장소는 약 1.2 공연 이었지만 여기에는 프로젝트가 사용하는 모든 라이브러리와 유틸리티가 포함되었습니다.

나는 일상적인 사용이 그다지 큰 영향을받을 것이라고 생각하지 않지만, 다른 개정을 통해 살펴 봐야 할 것은 약간 느려질 수 있습니다. 눈에 띄지 않을 수도 있습니다.

이제 SYS 관리자 관점에서 성능 병목 현상을 최소화하는 데 도움이되는 몇 가지가 있습니다. Subversion은 대부분 파일 기반 시스템이므로 다음을 수행 할 수 있습니다.

• 실제 저장소를 다른 드라이브에 넣으십시오
• SVN 이외의 파일 잠금 앱이 위의 드라이브에서 작동하지 않는지 확인하십시오.
• 드라이브를 최소 7,500 rpm으로 만듭니다. 10,000 rpm을 얻을 수 있지만 과잉 일 수 있습니다.
• 모든 사람이 같은 사무실에 있다면 LAN을 기가비트로 업데이트하십시오.

이것은 귀하의 상황에 대한 과잉 일 수 있지만, 이것이 다른 파일 집약적 인 응용 프로그램에서 일반적으로 수행 한 작업입니다.

당신이 "성장"전복이라면, 그렇다면 억지로 다음 단계가 될 것입니다. 매우 큰 프로젝트를 위해 가장 빠른 소스 제어 앱을 손에 넣습니다.

Answer 4

우리는 기가 바이트의 코드와 바이너리가있는 전복 서버를 실행하고 있으며 최대 2 만 개가 넘는 수정입니다. 아직 둔화가 없습니다.

Answer 5

Subversion은 델타 (차이) 만 2 개 개정 사이에 저장하므로 특히 코드 (텍스트) 만 커밋하고 바이너리 (이미지 및 문서) 만 커밋하는 경우 많은 공간을 절약하는 데 도움이됩니다.

또한 SVN을 사용하여 매우 큰 프로젝트를 많이 보았고 성능에 대해 불평하지 않았습니다.

어쩌면 체크 아웃 시간이 걱정 될까요? 그러면 이것이 실제로 네트워킹 문제라고 생각합니다.

아, 그리고 나는 2GB+의 물건 (코드, IMG, 문서)으로 CVS 리포지토리에서 작업했으며 성능 문제가 없었습니다. SVN은 CVS에서 큰 개선이기 때문에 걱정하지 않아도됩니다.

마음이 조금 쉬워지기를 바랍니다.)

Answer 6

나는 노화로 우리의 전복이 느려질 것이라고 생각하지 않습니다. 우리는 현재 여러 테라 바이트의 데이터를 가지고 있으며 대부분 바이너리가 있습니다. 우리는 매일 최대 50 기가 바이트의 데이터를 체크 아웃/커밋합니다. 전체적으로 우리는 현재 50000 개 개정을 가지고 있습니다. 우리는 FSFS를 스토리지 유형으로 사용하고 있으며 직접 SVN : (Windows Server) 또는 APACHE MOD_DAV_SVN (Gentoo Linux Server)을 통해 인터페이스하고 있습니다.

비교할 수있는 성능 비교를 위해 깨끗한 서버를 설정함에 따라 시간이 지남에 따라 SVN이 둔화 될 수 있음을 확인할 수 없습니다. 우리는 중요한 탈지를 측정 할 수 없었습니다.

그러나 나는 우리의 전복이 기본적으로 드물게 느리고 다른 컴퓨터 시스템을 사용해 보았을 때 분명히 전복 자체라고 말해야합니다.

알려지지 않은 이유로 전복은 서버 CPU 제한적으로 완전한 것으로 보입니다. 체크 아웃/커밋 요금은 클라이언트 당 15-30 메가 바이트/S로 제한됩니다. 하나의 서버 CPU 코어가 완료되기 때문입니다. 이것은 전체 서버 (~ 5 Terabyte, 50000 개정)와 거의 빈 저장소 (1 기가 바이트, 5 개 수정)와 동일합니다. 압축을 0 = OFF로 설정하는 것과 같은 튜닝은 이것을 향상시키지 못했습니다.

우리의 높은 대역 (~ 1 기가 바이트/s) fc-array 유휴, 다른 코어 유휴 및 네트워크 (현재 클라이언트의 경우 1 기가비트/S, 서버의 경우 10 기가비트/S) 유휴. 실제로 공회전하지는 않지만 사용 가능한 용량의 2-3% 만 사용된다면 공회전이라고합니다.

모든 구성 요소가 공회전하는 것을 보는 것은 정말 재미 없으며 작업 사본이 체크 아웃되거나 체크 아웃되기를 기다려야합니다. 기본적으로 체크 아웃/커밋 중에 항상 하나의 CPU 코어를 완전히 소비하여 서버 프로세스가 무엇을하고 있는지 전혀 모릅니다.

그러나 나는 단지 전복을 조정하는 방법을 찾으려고 노력하고 있습니다. 이것이 불가능한 경우 다른 시스템으로 전환해야 할 수도 있습니다.

따라서 답변 : SVN은 성능이 저하되지 않습니다. 초기에는 속도가 느립니다.

물론 (높은) 성능이 필요하지 않으면 문제가 없습니다. BTW. 위의 모든 내용은 Subversioon 1.7 최신 안정 버전에 적용됩니다.

Answer 7

속도를 늦출 수있는 유일한 작업은 여러 개정판 (예 : SVN 비난)에서 정보를 읽는 것입니다.

Answer 8

확실하지 않습니다 ..... Centos 5.2에서 Apache와 함께 SVN을 사용하고 있습니다. 작동합니다. 개정 번호는 8230이었고 ... 모든 클라이언트 컴퓨터에서 커밋이 너무 느려서 1KB 인 파일을 2 분 이상 기다려야했습니다. 큰 파일 크기가없는 1 개의 파일에 대해 이야기하고 있습니다.

그런 다음 새로운 저장소를 만들었습니다. Rev에서 시작했습니다. 1. 이제 OK가 작동합니다. 빠른. 중고 svnadmin xxxxxx를 작성합니다. FSFS 또는 BDB인지 확인하지 않았습니다 .....

Answer 9

어쩌면 워크 플로 개선을 고려해야 할 수도 있습니다.

저장소가 이러한 조건에서 성능 문제가 있는지는 모르겠지만, 당신은 제정신 개정으로 돌아갈 수 있습니다.

귀하의 경우, 귀하는 유효성 검사 프로세스를 포함 시키려고 할 수 있으므로 팀이 팀 리더 리포지토리에 커밋하고 각 팀은 읽기 전용 Clean Company Repos에 커밋하는 팀 관리자 레포에 전념합니다. 당신은 커밋이 정상으로 가야 할 단계에서 깨끗한 선택을합니다.

이런 식으로, 누구나 쉽게 탐색 할 수있는 깨끗한 사본으로 돌아갈 수 있습니다. 병합은 훨씬 쉬우 며 Dev는 여전히 원하는만큼 혼란을 저지를 수 있습니다.