Atlassian Crucible sangat lambat pada repositori besar

8

Perusahaan saya telah menjalankan percobaan Atlassian Crucible selama beberapa bulan sekarang. Untuk repositori yang berfungsi dengan baik, pengguna telah memberikan umpan balik yang sangat positif tentang alat ini. Masalah yang saya alami adalah bahwa kami memiliki beberapa proyek yang berbeda, masing-masing dengan repositori sendiri, dan beberapa repositori tersebut sangat besar. Satu repositori khususnya memiliki sejumlah besar cabang dan mungkin sekitar 9.000 file per cabang. Menjelajahi repositori di Crucible sangat lambat.

Crucible berjalan pada CentOS VM. VM memiliki 4GB RAM, dan saya telah menetapkan maksimum Crucible pada 3GB, yang saat ini menggunakan 2GB. Saya telah membawa ini dalam tiket dukungan dengan Atlassian, dan mereka menyarankan yang berikut:

Khususnya karena Anda memiliki repositori SVN yang agak besar, Anda mungkin akan menemukan bahwa Fisheye akan membuat file indeks besar pada disk. Untuk membantu meningkatkan kinerja, beberapa hal yang dapat Anda coba adalah:

Saya sudah mencoba semua hal ini sampai batas tertentu, tetapi sejauh ini tidak ada yang sangat membantu. Saya awalnya menjalankan Crucible pada kotak Windows dengan 2GB RAM menggunakan built in DB HSQL. Pindah ke MySQL di CentOS melihat peningkatan kinerja untuk beberapa repositori, dan membuat Crucible jauh lebih stabil, tetapi tampaknya tidak banyak membantu dengan repositori terbesar kami. Hanya ada begitu banyak file / cabang yang bisa saya kecualikan dari pengindeksan sambil mempertahankan kegunaan alat ini.

Karena itu, apakah ada yang punya tips tentang cara mempercepat Crucible di repositori besar, tanpa berinvestasi di perangkat keras yang luar biasa kuat?

Terima kasih!

Edit: Untuk memperjelas, karena saya tidak menyebutkan secara eksplisit di atas, saya sedang menggunakan FishEye.

Sunting 2: Karena saya awalnya memposting ini, kinerja agak membaik dengan rilis Crucible baru, tapi tetap saja tidak bagus. Tampaknya masalah ini memengaruhi banyak pengguna , termasuk beberapa dengan perangkat keras yang jauh lebih kuat daripada yang kami gunakan. Jadi, saya tidak percaya ini adalah masalah perangkat keras, tetapi lebih merupakan masalah dengan inefisiensi inheren dalam Crucible. Atlassian menyadari masalah ini dan akan memasukkan peningkatan kinerja lebih lanjut dalam rilis mendatang, jadi semoga perubahan itu memecahkan masalah kita.

Sunting 3: Saya sudah lupa berapa lama saya telah mengajukan pertanyaan ini, jadi dalam suntingan saya sebelumnya saya lupa menyebutkan bahwa situasi perangkat keras kami juga telah berubah sejak awalnya ditanyakan. Kami sekarang menjalankan Crucible pada server fisik khusus, masih menggunakan CentOS. Perangkat kerasnya masih sederhana (RAM 4GB, CPU quad core dan 500GB disk ganda di RAID 1 dengan cadangan eksternal), tetapi kami memang melihat sedikit peningkatan kinerja ketika kami pindah dari VM.

svn fisheye crucible Mitch Lindgren
sumber
Saya tahu ini adalah pertanyaan lama tetapi FYI bagi siapa saja yang menemukan ini melalui pencarian, dalam pengalaman saya (sangat terbatas) baru-baru ini hanya memindahkan database ke contoh PostgreSQL eksternal akan memberi Anda speedup utama untuk repo besar (jelas, ini mengasumsikan bahwa mesin adalah cukup kuat untuk menjalankan contoh ukuran postgres yang layak; Saya juga mengubah pengaturan vaksin sedikit untuk perangkat keras saya, tetapi lebih cepat, lebih cepat). Ini secara drastis akan mengurangi waktu akses disk, dan kinerja dan kegunaan jauh lebih baik daripada mysql (atau setidaknya, tampaknya untuk fecru)
Sam Whited

Jawaban:

2

Karena bermigrasi ke MySQL membuat perbedaan nyata untuk beberapa repositori, pertimbangkan menyetel basis data untuk perbaikan lebih lanjut. Mengubah beberapa my.cnfnilai dari default dapat membuat perbedaan besar. Lihat Dasar - Dasar Pengoptimalan Kinerja InnoDB untuk informasi lebih lanjut. Juga periksa permintaan lambat dengan mengaktifkan log permintaan lambat dan tambahkan indeks yang sesuai.

Tebakan saya berikutnya adalah kecepatan jaringan: apakah instance Crucible Anda pada jaringan lokal kabel yang sama dengan repositori SVN Anda? Anda juga dapat mencoba memberikan uji coba Crucible pada mesin yang sama dengan repositori utama Anda jika mungkin untuk menghilangkan latensi jaringan sebagai penyebabnya.

Dan saya tahu ini mungkin sulit tergantung pada lingkungan kerja Anda, tetapi menjalankan Crucible dalam VM mungkin tidak membantu; Atlassian membuat catatan tentang ini di halaman Praktik Terbaik untuk Konfigurasi Crucible yang sangat singkat . Saya yakin Anda sudah menemukannya, tetapi saya juga akan menyebutkan halaman Tuning FishEye untuk pembaca lain.

Saya juga memiliki masalah kinerja untuk proyek-proyek besar, tetapi menghubungkan banyak kelambatan ke antarmuka web Crucible yang berat. Ini terutama benar setelah mengklik sebentar (halaman yang sebelumnya dilihat dalam ulasan tetap di jendela browser, bahkan ketika tersembunyi dari pandangan). Pengembang kami memperhatikan sedikit peningkatan kecepatan dengan beralih ke Google Chrome. Periksa juga Konektor IDE Atlassian jika ada plugin yang kompatibel untuk lingkungan pengembangan Anda. Konektor Eclipse IDE memiliki masalah sendiri terakhir kali saya menggunakannya (beberapa bulan yang lalu), tetapi setidaknya bisa menangani set file besar tanpa menutup telepon.

Bergantung pada praktik pengembangan perusahaan Anda, Anda dapat berhenti memindai sejumlah besar cabang kode (dengan asumsi banyak dari mereka tidak lagi aktif), dan menonaktifkan repositori untuk proyek yang sudah selesai / mati sampai dibutuhkan. Perusahaan saya menggunakan tim yang sangat kecil pada sejumlah besar proyek, sehingga sebagian besar waktu kami bekerja terutama trunk, membuat cabang pengecualian; karena itu kami secara eksplisit menambahkan cabang untuk memindai alih-alih memasukkan semua cabang secara default. Pastikan juga Anda tidak memindai tag secara tidak sengaja.

Bagaimana penggunaan CPU Anda di kotak Crucible? Jika Anda menggunakan SVN di belakang Apache HTTPD, periksa berapa banyak koneksi yang dikonsumsi oleh Crucible selama pemindaian repositori besar. Selain itu, saya tidak yakin apa lagi yang bisa Anda lihat (mungkin kecepatan disk? Frekuensi pemindaian repositori?), Tetapi mudah-mudahan tips di atas akan sedikit membantu.

Dave
sumber
Terima kasih atas respon yang mendetail. Saya memperbarui pertanyaan awal saya karena saya lupa menyertakan info perangkat keras yang diperbarui dalam suntingan saya sebelumnya. Kecepatan jaringan mungkin merupakan masalah dalam pengindeksan awal tetapi seharusnya tidak menyebabkan masalah setelah indeks telah dibuat (yang mana kita melihat banyak rasa sakit - saat menelusuri file yang diindeks.) Kami akhirnya pindah Crucible ke kotak fisik khusus dan melihat peningkatan kinerja sederhana. Sebagian besar pengembang kami menggunakan Chrome, dan saya sudah memperingatkan semua orang menggunakan Crucible NOT untuk menggunakan IE sebagai mesin JavaScript-nya (sebelum IE9) sangat lambat.
Mitch Lindgren
Saya tidak menyadari file yang dilihat sebelumnya disimpan dalam memori, jadi saya akan pastikan untuk memberitahu semua orang untuk me-refresh ketika segalanya menjadi lambat. FYI, meskipun, Atlassian benar-benar kehilangan dukungan untuk konektor Eclipse, yang saya dapatkan banyak keluhan. Mereka memang memiliki konektor untuk IDE lain tetapi Eclipse adalah yang besar bagi kami. Sedangkan untuk cabang, beberapa tim kami tidak menggunakannya dan beberapa melakukannya secara ekstensif. Tim yang tidak menggunakan cabang baik-baik saja. Tim-tim yang mengalami kelambatan serius. Sayangnya meminta mereka untuk mengubah proses mereka agak keluar dari pertanyaan.
Mitch Lindgren
Saya telah melihat kinerja MySQL sebelumnya dan akan melakukannya lagi. Sepertinya hambatan besar hanya melintasi file indeks. Disk yang lebih cepat mungkin membantu di sini, tetapi disk kami sudah cukup cepat (walaupun bukan yang teratas. Sebelum pindah ke server baru, saya melihat banyak IO menunggu, tetapi saya tidak melihat terlalu banyak lagi.) Saya pikir yang bisa saya lakukan sekarang adalah menunggu peningkatan kinerja yang dipuji-puji Atlassian. Saya akan menandai jawaban Anda sebagai diterima, karena saya pikir itu berisi banyak informasi berharga bagi orang lain yang mungkin berada dalam situasi yang sama.
Mitch Lindgren
1

> 4 G RAM bukanlah perangkat keras yang "sangat kuat". Dengan asumsi Anda memiliki 25 pengguna dan Anda menggunakan Fisheye (yang Anda sebutkan), Anda menghabiskan $ 4400 hanya pada perangkat lunak. $ 4rb di Dell bisa membelikan Anda server dengan 48G RAM.

Juga, apakah Anda menggunakan JVM 64-bit? Dokumen menunjukkan bahwa Anda akan melihat jejak memori yang lebih baik (seperti, kurang dari itu) pada JVM 32-bit.

Bill Weiss
sumber
Terimakasih atas infonya. Kami menggunakan JVM 64-bit. Saya akan melihat apakah saya dapat beralih ke 32-bit dan melihat apakah itu membantu. Sunting: Ups - tekan enter dan itu menyimpan komentar saya alih-alih menambahkan baris baru. Salahku. Mengenai perangkat keras, ini adalah sesuatu yang menarik: situasi perangkat keras agak di luar kendali saya, dan sulit bagi saya untuk membenarkan peningkatan pengeluaran sampai kita tahu bahwa alat itu akan bekerja untuk semua tim yang perlu menggunakannya. Saya akan melihat apakah ada yang dapat dilakukan untuk pengaturan yang ada (misalnya, mengalokasikan lebih banyak memori untuk VM itu.)
Mitch Lindgren
Permintaan maaf untuk komentar ganda, tetapi satu pertanyaan lain: apakah Anda yakin bahwa ingatan adalah masalahnya? Saya menyadari 4GB tidak banyak, tetapi Fisheye / Crucible bahkan tidak memaksimalkan 3GB maksimum yang saya tetapkan pada JVM.
Mitch Lindgren
Saya tidak yakin apakah itu masalah Anda, tetapi saya hanya menunjukkan bahwa itu bukan "sangat kuat". Meskipun kinerjanya buruk, dapatkah Anda mengumpulkan beberapa statistik sistem? Lari top, iostatdan yang lainnya, dan lihat apa yang menyakitkan.
Bill Weiss
"Sangat kuat" adalah pilihan kata yang buruk. Saya hanya merasa bahwa server $ 4.000 dengan RAM 48GB adalah persyaratan yang tidak wajar untuk aplikasi web yang digunakan oleh begitu sedikit pengembang.
Mitch Lindgren
3
$ 4400/25 pengguna / 2 tahun == $ 88 / dev / tahun. Berapa banyak jam dev setahun yang harus Anda selamatkan?
Bill Weiss
0

Walaupun saya sendiri belum mencobanya, saya mengalami gejala yang persis sama dengan Anda.

Saat ini saya sedang mempertimbangkan mematikan info diff yang tersimpan untuk repositori yang menyinggung. Saya mengajukan pertanyaan di situs Tanya Jawab Atlassian dan mendapatkan beberapa saran yang menjanjikan.

Masalah saya sama - pengindeksan tidak menjadi masalah, ini adalah jejak disk yang sangat besar yang berjalan pada array disk yang berkinerja buruk di VM. Karena saya tidak dapat memutakhirkan disk saat ini, saya perlu mencari cara lain untuk mengatasinya. Penjawab dalam posting saya di atas mengatakan bahwa menghapus info diff akan mengurangi jejak disk dengan mengorbankan kehilangan kemampuan untuk mencari baris yang ditambahkan / dihapus . Meskipun dia juga menyarankan bahwa itu tidak akan mempengaruhi kecepatan menjelajah file dengan sejarah panjang.

Jika orang lain melihat ini & dapat melaporkan keberhasilan / kegagalan dengan sakelar ini, silakan komentar di sini.

Oh dan saya menjalankan 2.7.13 dengan masalah kinerja yang sama.

Mark McDonald
sumber