Atlassian Crucible rất chậm trên kho lớn

Công ty của tôi đã chạy thử nghiệm Atlassian Crucible được vài tháng nay. Đối với các kho lưu trữ hoạt động đúng cách, người dùng đã đưa ra phản hồi rất tích cực về công cụ này. Vấn đề tôi gặp phải là chúng tôi có một số dự án khác nhau, mỗi dự án có kho lưu trữ riêng và một số kho lưu trữ đó rất lớn. Một kho lưu trữ đặc biệt có số lượng lớn các nhánh và có thể khoảng 9.000 tệp trên mỗi nhánh. Duyệt kho lưu trữ đó trong Crucible cực kỳ chậm.

Crucible đang chạy trên máy ảo CentOS. VM có 4GB RAM và tôi đã đặt mức tối đa của Crucible là 3GB, trong đó hiện tại nó đang sử dụng 2GB. Tôi đã mang cái này lên trong một vé hỗ trợ với Atlassian và họ đề nghị như sau:

Đặc biệt bởi vì bạn có một kho lưu trữ SVN khá lớn, bạn có thể sẽ thấy rằng Fisheye sẽ tạo một tệp chỉ mục lớn trên đĩa. Để giúp cải thiện hiệu suất, một số điều bạn có thể thử là:

• Tăng bộ nhớ khả dụng cho Fisheye.
• Di chuyển đến một cơ sở dữ liệu bên ngoài .
• Không bao gồm các tệp và thư mục từ chỉ mục của bạn không cần thiết .

Tôi đã thử tất cả những điều này ở một mức độ nào đó, nhưng cho đến nay không có gì giúp được nhiều. Ban đầu tôi đang chạy Crucible trên một hộp Windows với 2GB RAM bằng cách sử dụng DB HSQL tích hợp. Chuyển sang MySQL trên CentOS đã thấy hiệu suất tăng đối với một số kho lưu trữ và làm cho Crucible ổn định hơn nhiều, nhưng dường như không giúp được gì nhiều với kho lưu trữ lớn nhất của chúng tôi. Chỉ có rất nhiều tệp / nhánh tôi có thể loại trừ khỏi việc lập chỉ mục trong khi vẫn duy trì tính hữu dụng của công cụ.

Trong trường hợp đó, có ai có bất cứ lời khuyên nào về cách tăng tốc Crucible trên các kho lưu trữ lớn mà không cần đầu tư vào phần cứng cực kỳ mạnh mẽ không?

Cảm ơn!

Chỉnh sửa: Để làm rõ, vì tôi đã không đề cập rõ ràng ở trên, tôi đang sử dụng FishEye.

Chỉnh sửa 2: Vì ban đầu tôi đã đăng bài này, hiệu suất đã được cải thiện phần nào với các bản phát hành Crucible mới, nhưng nó vẫn không tuyệt vời bằng bất kỳ phương tiện nào. Có vẻ như vấn đề này ảnh hưởng đến nhiều người dùng , kể cả một số người có phần cứng mạnh hơn nhiều so với chúng ta đang sử dụng. Vì vậy, tôi không tin đó là vấn đề phần cứng, mà là vấn đề với sự kém hiệu quả vốn có trong Crucible. Atlassian nhận thức được vấn đề và sẽ bao gồm các cải tiến hiệu suất hơn nữa trong các phiên bản tương lai, vì vậy hy vọng những thay đổi đó sẽ giải quyết vấn đề của chúng tôi.

Chỉnh sửa 3: Tôi đã quên cách đây bao lâu tôi đã hỏi câu hỏi này, vì vậy trong lần chỉnh sửa trước tôi đã bỏ qua việc đề cập rằng tình hình phần cứng của chúng tôi cũng đã thay đổi kể từ khi được hỏi ban đầu. Chúng tôi hiện đang chạy Crucible trên một máy chủ vật lý chuyên dụng, vẫn đang sử dụng CentOS. Phần cứng vẫn còn khiêm tốn (RAM 4GB, CPU lõi tứ và đĩa kép 500 GB trong RAID 1 với bản sao lưu ngoài), nhưng chúng tôi đã thấy hiệu suất tăng nhẹ khi chúng tôi rời khỏi VM.

Vì việc di chuyển sang MySQL đã tạo ra sự khác biệt đáng chú ý đối với một số kho lưu trữ, hãy xem xét điều chỉnh cơ sở dữ liệu để cải thiện thêm. Thay đổi một số my.cnfgiá trị từ mặc định có thể tạo ra sự khác biệt lớn. Xem thông tin cơ bản về tối ưu hóa hiệu suất của InnoDB để biết thêm thông tin. Đồng thời kiểm tra các truy vấn chậm bằng cách bật nhật ký truy vấn chậm và thêm chỉ mục khi thích hợp.

Dự đoán tiếp theo của tôi sẽ là tốc độ mạng: là đối tượng Crucible của bạn trên cùng một mạng cục bộ có dây như kho lưu trữ SVN của bạn? Bạn cũng có thể thử cho Crucible chạy thử trên cùng một máy với kho lưu trữ chính của bạn nếu có thể để loại bỏ độ trễ mạng là thủ phạm.

Và tôi biết điều đó có thể khó khăn tùy thuộc vào môi trường làm việc của bạn, nhưng chạy Crucible trong VM có thể không giúp được gì; Atlassian ghi chú điều này trên trang Thực tiễn tốt nhất rất ngắn gọn cho cấu hình quan trọng của họ . Tôi chắc chắn rằng bạn đã bắt gặp nó, nhưng tôi cũng sẽ đề cập đến trang Tune FishEye cho những người đọc khác.

Tôi cũng có vấn đề về hiệu năng cho các dự án lớn, nhưng thuộc tính rất chậm của giao diện web nặng của Crucible. Điều này đặc biệt đúng sau khi nhấp xung quanh một chút (các trang được xem trước đó trong bài đánh giá vẫn còn trong cửa sổ trình duyệt, ngay cả khi bị ẩn khỏi tầm nhìn). Các nhà phát triển của chúng tôi đã nhận thấy sự gia tăng tốc độ nhẹ bằng cách chuyển sang Google Chrome. Ngoài ra, hãy kiểm tra Atlassian IDE Connector nếu có một plugin tương thích cho môi trường phát triển của bạn. Trình kết nối IDE Eclipse có vấn đề của chính nó lần cuối tôi sử dụng nó (nhiều tháng trước), nhưng ít nhất nó có thể xử lý các tập tin lớn mà không bị treo.

Tùy thuộc vào thực tiễn phát triển của công ty bạn, bạn có thể ngừng quét một số lượng lớn các nhánh mã (giả sử nhiều trong số chúng không còn hoạt động) và vô hiệu hóa kho lưu trữ cho các dự án đã hoàn thành / đã chết cho đến khi chúng cần. Công ty của tôi sử dụng các nhóm rất nhỏ trong một số lượng lớn các dự án, vì vậy hầu hết thời gian chúng tôi làm việc chủ yếu trunk, làm cho các chi nhánh trở thành ngoại lệ; do đó chúng tôi rõ ràng thêm các nhánh để quét thay vì bao gồm tất cả các nhánh theo mặc định. Cũng đảm bảo rằng bạn không vô tình quét thẻ.

Việc sử dụng CPU của bạn trên hộp Crucible như thế nào? Nếu bạn đang sử dụng SVN đằng sau Apache HTTPD, hãy kiểm tra xem Crucible đã sử dụng bao nhiêu kết nối trong quá trình quét kho lưu trữ lớn. Ngoài ra, tôi không chắc bạn có thể nhìn gì khác (có thể là tốc độ đĩa? Tần số quét của kho lưu trữ?), Nhưng hy vọng các mẹo trên sẽ giúp ích được một chút.

> 4 G RAM không phải là phần cứng "cực kỳ mạnh". Giả sử bạn đã có 25 người dùng và bạn đang sử dụng Fisheye (mà bạn đề cập), bạn sẽ chi 4400 đô la cho phần mềm. $ 4k tại Dell có thể mua cho bạn một máy chủ có 48G RAM.

Ngoài ra, bạn có đang sử dụng JVM 64 bit không? Các tài liệu đề xuất rằng bạn sẽ thấy dung lượng bộ nhớ tốt hơn (như trong, ít hơn) trên JVM 32 bit.

Trong khi tôi chưa thực sự thử điều này, tôi cũng trải qua các triệu chứng giống như bạn.

Tôi hiện đang xem xét tắt thông tin khác biệt được lưu trữ cho các kho lưu trữ vi phạm. Tôi đã hỏi câu hỏi trên trang web Hỏi & Đáp của Atlassian và nhận được một số lời khuyên đầy hứa hẹn.

Vấn đề của tôi cũng vậy - lập chỉ mục không phải là vấn đề, đó là một dấu chân đĩa lớn chạy trên một mảng đĩa hoạt động kém trong VM. Vì hiện tại tôi không thể nâng cấp đĩa, tôi cần tìm cách khác xung quanh nó. Người trả lời trong bài viết của tôi ở trên nói rằng việc xóa thông tin khác biệt sẽ làm giảm dấu chân đĩa với chi phí mất khả năng tìm kiếm các dòng được thêm / xóa . Mặc dù ông cũng gợi ý rằng nó sẽ không ảnh hưởng đến tốc độ duyệt các tệp có lịch sử lâu dài.

Nếu ai đó thấy điều này & có thể báo cáo thành công / thất bại với công tắc này, vui lòng bình luận tại đây.

Oh và tôi đang chạy 2.7.13 với các vấn đề hiệu suất tương tự.