Wydajność SVN po wielu zmianach

Subversion przechowuje najbardziej aktualną wersję jako pełny tekst, z wstecznie wyglądającymi diffami. Oznacza to, że aktualizacje do głowy są zawsze szybkie, a to, za co stopniowo płacisz, wygląda coraz bardziej wstecz w historii.

Osobiście nie miałem do czynienia z repozytoriami Subversion z bazami kodowymi większymi niż 80K LOC dla rzeczywistego projektu. Największe repozytorium, jakie miałem, to około 1.2 gigs, ale to obejmowało wszystkie biblioteki i narzędzia, z których korzysta projekt.

Nie sądzę, aby codzienne użytkowanie miało tak duży wpływ, ale wszystko, co trzeba przejrzeć różne wersje, może nieco spowolnić. To może nawet nie być zauważalne.

Teraz, z punktu widzenia administratora sys, istnieje kilka rzeczy, które mogą pomóc zminimalizować wąskie gardła wydajności. Ponieważ Subversion jest głównie systemem opartym na plikach, możesz to zrobić:

• Umieść rzeczywiste repozytoria na innym dysku
• upewnij się, że żadne aplikacje blokujące pliki, inne niż svn, nie działają na powyższym dysku
Ustaw Napędy co najmniej 7500 obr. / min. Możesz spróbować uzyskać 10,000 RPM, ale może to być przesada Zaktualizuj LAN do gigabit, jeśli wszyscy są w tym samym biurze.

To to może być przesada dla twojej sytuacji, ale to zwykle robię dla innych aplikacji intensywnie wykorzystujących pliki.

Jeśli kiedykolwiek "wyrośniesz" Subversion, to Perforce będzie twoim następnym krokiem naprzód. To najszybsza aplikacja do kontroli źródeł dla bardzo dużych projektów.

Uruchamiamy serwer subversion z gigabajtowym kodem i binariami, który ma ponad dwadzieścia tysięcy wersji. Żadnych spowolnień.

Subversion przechowuje tylko deltę (różnice), pomiędzy 2 wersjami, więc pomaga to zaoszczędzić dużo miejsca, szczególnie jeśli zatwierdzasz tylko kod (tekst) i nie masz plików binarnych (obrazów i dokumentów).

DODATKOWO widziałem wiele bardzo dużych projektów wykorzystujących svn i nigdy nie narzekałem na wydajność.

Może martwisz się o czas realizacji zamówienia? więc myślę, że to byłby naprawdę problem z siecią.

Oh, Ive pracował na repozytoriach CVS z 2GB + rzeczy( kod, imgs, docs) i nigdy nie miał problemów z wydajnością. Ponieważ svn jest wielkim ulepszeniem w cvs, nie sądzę, że powinieneś się martwić.

Mam nadzieję, że to trochę ułatwi twój umysł;)

Nie sądzę, aby nasza wywrotowość spowolniła przez starzenie się. Obecnie mamy kilka terabajtów danych, głównie binarnych. Kasujemy / zatwierdzamy codziennie do 50 gigabajtów danych. W sumie mamy obecnie 50000 rewizji. Używamy FSFS jako typu pamięci masowej i łączymy się bezpośrednio z SVN: (Windows server) lub poprzez Apache mod_dav_svn (Gentoo Linux Server).

Nie mogę potwierdzić, że powoduje to spowolnienie svn z czasem, ponieważ skonfigurowaliśmy czysty serwer do porównywania wydajności, który można porównać do. Nie mogliśmy zmierzyć znaczącej degresji.

Muszę jednak powiedzieć, że nasza subversion jest domyślnie niezbyt powolna i oczywiście jest to subversion, jak próbowaliśmy z innym systemem komputerowym.

Z nieznanych powodów subversion wydaje się być całkowicie ograniczone przez procesor serwera. Nasze stawki checkout / commit są ograniczone do 15-30 megabajtów / s na klienta, ponieważ wtedy jeden rdzeń CPU serwera jest całkowicie zużyty. To samo dotyczy prawie pustego repozytorium (1 gigabajt, 5 wersji) jak dla naszego pełnego serwera (~5 terabajt, 50000 wersji). Strojenie, takie jak ustawienie kompresji na 0 = off, nie poprawiło tego.

Nasze wysokie pasmo (dostarcza ~1 gigabajt / s) FC-Array Idle, Pozostałe rdzenie idle i sieci (obecnie 1 GigaBit/s dla Klientów, 10 Gigabit / s dla serwera) również Idle. OK, nie bardzo na biegu jałowym, ale jeśli tylko 2-3% dostępnej pojemności jest używany nazywam to na biegu jałowym.

To nie jest prawdziwa zabawa, aby zobaczyć wszystkie komponenty na biegu jałowym i musimy poczekaj, aż nasze kopie robocze zostaną sprawdzone lub dostarczone. Zasadniczo nie mam pojęcia, co robi proces serwera, w pełni zużywając jeden rdzeń CPU przez cały czas podczas checkout / commit.

Jednak staram się znaleźć sposób na dostrojenie subversion. Jeśli nie jest to możliwe, być może będziemy musieli przełączyć się na inny system.

Dlatego: odpowiedź: Nie SVN nie pogarsza wydajności, jest początkowo powolny.

Oczywiście jeśli nie potrzebujesz (wysokiej) wydajności nie będziesz miał problem. Btw. wszystko to dotyczy najnowszej stabilnej wersji subversioon 1.7

Jedynymi operacjami, które mogą spowolnić, są rzeczy, które odczytują informacje z wielu wersji (np. SVN).

Nie jestem pewien..... Używam SVN z apache na Centos 5.2. Działa ok. Numer rewizji to 8230... A na wszystkich maszynach klienckich Commit był tak powolny, że musieliśmy czekać co najmniej 2min na plik o rozmiarze 1KB. Mówię o 1 pliku, który nie ma dużego rozmiaru pliku.

Potem zrobiłem nowe repozytorium. Zaczęty przez rev.1 Teraz Działa ok. Szybko. używany svnadmin create xxxxxx. nie sprawdzałem czy jest to FSFS czy BDB.....

Może powinieneś rozważyć poprawę przepływu pracy.

Nie wiem, czy repos będzie miał problemy z perf w tych warunkach, ale można wrócić do rozsądnej rewizji będzie.

W Twoim przypadku możesz dołączyć proces walidacji, więc commit zespołu w repo lidera zespołu, a każdy z nich commit do repo menedżera zespołu, który commit do Read-only clean company repo. Musisz dokonać czystego wyboru na etapie tego, co commit musi przejść do top.

W ten sposób każdy może wrócić do czystej kopii, z łatwą do przeglądania historią. Scalanie jest o wiele łatwiejsze, a dev może nadal popełniać swój bałagan, ile chce.