Hiệu suất SVN sau nhiều lần sửa đổi

Question

Dự án của tôi hiện đang sử dụng kho lưu trữ svn có thể nhận được hàng trăm bản sửa đổi mới mỗi ngày. Kho lưu trữ nằm trên máy chủ Win2k3 và được phục vụ thông qua Apache/mod_dav_svn.

Tôi lo ngại rằng theo thời gian hiệu suất sẽ bị giảm do quá nhiều lần sửa đổi.
Nỗi sợ này có hợp lý không?
Chúng tôi đã lên kế hoạch nâng cấp lên 1.5, vì vậy việc có hàng nghìn tệp trong một thư mục sẽ không có vấn đề gì trong thời gian dài.

Subversion trên các cửa hàng khu vực đồng bằng (sự khác biệt), giữa 2 phiên bản, vì vậy điều này giúp tiết kiệm rất nhiều không gian, đặc biệt nếu bạn chỉ cam kết mã (văn bản) và không có mã nhị phân (hình ảnh và tài liệu).

Điều đó có nghĩa là để kiểm tra bản sửa đổi 10 của tệp foo.baz, svn sẽ sửa đổi 1 và sau đó áp dụng các khoảng 2-10?

Answer 1

Loại repo nào bạn có? FSFS hoặc BDB?

(Giả sử FSFS cho bây giờ, vì đó là mặc định.)

Trong trường hợp của FSFS, mỗi phiên bản được lưu giữ như một diff so với trước đó. Vì vậy, bạn sẽ nghĩ rằng có, sau nhiều lần sửa đổi, nó sẽ rất chậm.

Tuy nhiên, đây không phải là trường hợp. FSFS sử dụng những gì được gọi là "bỏ qua deltas" để tránh phải làm quá nhiều tra cứu trên vòng quay trước đó.

(Vì vậy, nếu bạn đang sử dụng một repo FSFS, câu trả lời Brad Wilson là sai.)

Trong trường hợp của một repo BDB, các HEAD (mới nhất) sửa đổi là toàn văn, nhưng các phiên bản trước đó là được xây dựng như một loạt các khác biệt với đầu. Điều này có nghĩa là các vòng quay trước đó phải được tính lại sau mỗi lần commit.

Để biết thêm thông: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

T.B. Repo của chúng tôi khoảng 20GB, với khoảng 35.000 bản sửa đổi và chúng tôi đã không nhận thấy bất kỳ sự xuống cấp hiệu suất nào.

Answer 2

Subversion chỉ lưu trữ đồng bằng (khác biệt), giữa 2 bản sửa đổi, vì vậy điều này giúp tiết kiệm rất nhiều không gian, đặc biệt nếu bạn chỉ cam kết mã (văn bản) và không có nhị phân (hình ảnh và tài liệu).

Ngoài ra, tôi đã thấy rất nhiều dự án rất lớn sử dụng svn và không bao giờ phàn nàn về hiệu suất.

Có thể bạn đang lo lắng về thời gian thanh toán? thì tôi đoán đây thực sự là một vấn đề về mạng.

Ồ, và tôi đã làm việc trên các kho CVS với 2Gb + nội dung (mã, imgs, tài liệu) và không bao giờ gặp vấn đề về hiệu năng. Kể từ khi svn là một cải tiến lớn trên cvs tôi không nghĩ rằng bạn nên lo lắng về.

Hy vọng nó giúp dễ dàng tâm trí của bạn một chút;)

Answer 3

Các hoạt động duy nhất có khả năng làm chậm những điều mà đọc thông tin từ nhiều sửa đổi (ví dụ SVN Đổ lỗi).

Answer 4

Subversion lưu trữ phiên bản mới nhất dưới dạng văn bản đầy đủ, với các khác biệt tìm kiếm ngược. Điều này có nghĩa là các bản cập nhật cho phần đầu luôn luôn nhanh chóng và những gì bạn phải trả thêm cho việc tìm kiếm xa hơn và xa hơn trong lịch sử.

Answer 5

Cá nhân tôi chưa xử lý các kho lưu trữ Subversion có mã số lớn hơn 80K LOC cho dự án thực tế. Kho lưu trữ lớn nhất mà tôi thực sự có được là khoảng 1,2 hợp đồng biểu diễn, nhưng điều này bao gồm tất cả các thư viện và tiện ích mà dự án sử dụng.

Tôi không nghĩ rằng việc sử dụng hàng ngày sẽ bị ảnh hưởng nhiều, nhưng bất cứ điều gì cần phải xem xét thông qua các bản sửa đổi khác nhau có thể làm chậm một chút. Nó có thể thậm chí không đáng chú ý.

Bây giờ, từ quan điểm quản trị viên của sys, có một vài điều có thể giúp bạn giảm thiểu tắc nghẽn hiệu suất. Kể từ Subversion là chủ yếu là một hệ thống tập tin dựa trên, bạn có thể làm điều này:

• Đặt kho thực tế trong một ổ đĩa khác nhau
• Hãy chắc chắn rằng không có tập tin khóa ứng dụng, trừ svn, đang làm việc trên các ổ đĩa trên
• Làm cho các ổ đĩa có ít nhất 7.500 RPM.Bạn có thể thử nhận 10.000 RPM nhưng có thể quá mức cần thiết
• Cập nhật LAN thành gigabit, nếu mọi người ở cùng một văn phòng.

Điều này có thể quá mức cần thiết cho trường hợp của bạn, nhưng đó là những gì tôi thường làm cho các ứng dụng tập tin khác.

Nếu bạn từng "phát triển" Subversion, thì Perforce sẽ là bước tiếp theo của bạn. Nó đưa xuống ứng dụng kiểm soát nguồn nhanh nhất cho các dự án rất lớn.

Answer 6

Chúng tôi đang chạy máy chủ lật đổ có giá trị mã gigabyte và mã nhị phân, và lên đến hơn hai mươi nghìn bản sửa đổi. Chưa có sự chậm lại nào.

Answer 7

Tôi không chắc ..... Tôi đang sử dụng SVN với apache trên CentOS 5.2. Hoạt động ok. Số sửa đổi là 8230 một cái gì đó như thế ... Và trên tất cả các máy khách, Commit quá chậm nên chúng tôi phải chờ ít nhất 2 phút cho một tệp có dung lượng 1kb. Tôi đang nói về 1 tệp không có kích thước lớn.

Sau đó, tôi đã tạo một kho lưu trữ mới. Bắt đầu từ rev. 1. Bây giờ hoạt động ok. Nhanh. sử dụng svnadmin tạo xxxxxx. không kiểm tra xem đó là FSFS hay BDB .....

Answer 8

Có thể bạn nên xem xét cải thiện quy trình làm việc của mình.

Tôi không biết liệu bản repo có vấn đề về độ trong những điều kiện này hay không, nhưng bạn có khả năng quay lại bản sửa đổi lành mạnh.

Trong trường hợp của bạn, bạn có thể muốn bao gồm quy trình xác thực, do đó, một nhóm cam kết trong một nhà lãnh đạo nhóm, và mỗi người cam kết với người quản lý nhóm repo người cam kết chỉ đọc repos công ty sạch. Bạn đã thực hiện một lựa chọn sạch sẽ ở giai đoạn của những gì cam kết phải đi đến đỉnh.

Bằng cách này, bất kỳ ai cũng có thể quay lại bản sao sạch sẽ, với lịch sử duyệt web dễ dàng. Hợp nhất là dễ dàng hơn nhiều, và dev vẫn có thể cam kết mớ hỗn độn của họ nhiều như họ muốn.

Answer 9

Tôi không nghĩ rằng sự lật đổ của chúng tôi bị chậm lại do lão hóa. Chúng tôi hiện có một số dữ liệu TeraBytes, chủ yếu là nhị phân. Chúng tôi thanh toán/cam kết hàng ngày tối đa 50 GigaByte dữ liệu.Tổng cộng chúng tôi hiện có 50000 bản sửa đổi. Chúng tôi đang sử dụng FSFS làm loại lưu trữ và đang giao tiếp trực tiếp SVN: (Windows server) hoặc thông qua Apache mod_dav_svn (Gentoo Linux Server).

Tôi không thể xác nhận rằng điều này khiến svn chậm lại theo thời gian, khi chúng tôi thiết lập máy chủ sạch để so sánh hiệu suất mà chúng tôi có thể so sánh. Chúng ta KHÔNG thể đo được sự suy giảm đáng kể.

Tuy nhiên tôi phải nói rằng lật đổ của chúng tôi là không phổ biến chậm theo mặc định và rõ ràng nó là subversion chính nó như chúng tôi đã thử với một hệ thống máy tính.

Vì một số lý do không rõ, lật đổ dường như hoàn toàn bị giới hạn CPU máy chủ. Tỷ lệ thanh toán/cam kết của chúng tôi được giới hạn ở mức từ 15-30 MB/s cho mỗi khách hàng vì sau đó một lõi CPU máy chủ được sử dụng hoàn toàn. Điều này là như nhau cho một kho lưu trữ gần như trống rỗng (1 GigaByte, 5 sửa đổi) như cho máy chủ đầy đủ của chúng tôi (~ 5 TeraByte, 50000 sửa đổi). Điều chỉnh như thiết lập nén thành 0 = off không cải thiện được điều này.

Băng thông cao của chúng tôi (cung cấp ~ 1 GigaByte/giây) FC-Array idles, các lõi khác nhàn rỗi và mạng (hiện tại cũng là 1 GigaBit/s cho khách hàng, 10 GigaBits/s cho máy chủ). Được rồi không thực sự nhàn rỗi nhưng nếu chỉ 2-3% dung lượng có sẵn được sử dụng tôi gọi nó là chạy không tải.

Thật không có gì thú vị khi thấy tất cả các thành phần không hoạt động và chúng tôi cần phải chờ các bản sao làm việc của chúng tôi được kiểm tra hoặc được gửi đi. Về cơ bản tôi không có ý tưởng những gì quá trình máy chủ đang làm bằng cách tiêu thụ đầy đủ một lõi CPU tất cả thời gian trong quá trình thanh toán/cam kết.

Tuy nhiên, tôi chỉ đang cố tìm cách điều chỉnh lật đổ. Nếu điều này là không thể, chúng tôi có thể cần phải chuyển sang một hệ thống khác.

Do đó: Trả lời: Không SVN không bị suy giảm hiệu suất ban đầu nó chậm.

Tất nhiên nếu bạn không cần (hiệu suất cao), bạn sẽ không gặp vấn đề gì. Btw. tất cả những điều trên áp dụng cho subversioon 1.7 phiên bản ổn định mới nhất