Crisol Atlassian muy lento en repositorio grande

8

Mi compañía ha estado ejecutando una prueba de Atlassian Crucible durante algunos meses. Para los repositorios donde funciona correctamente, los usuarios han brindado comentarios muy positivos sobre la herramienta. El problema que tengo es que tenemos varios proyectos diferentes, cada uno con su propio repositorio, y algunos de esos repositorios son muy grandes. Un repositorio en particular tiene una gran cantidad de ramas y probablemente alrededor de 9,000 archivos por rama. Explorar ese repositorio en Crucible es extremadamente lento.

Crucible se está ejecutando en una VM CentOS. La VM tiene 4 GB de RAM, y he establecido el máximo de Crucible en 3 GB, de los cuales actualmente usa 2 GB. Lo mencioné en un ticket de soporte con Atlassian, y sugirieron lo siguiente:

En particular, debido a que tiene un repositorio SVN bastante grande, probablemente encontrará que Fisheye creará un archivo de índice grande en el disco. Para ayudar a mejorar el rendimiento, algunas cosas que puedes probar son:

He intentado todas estas cosas hasta cierto punto, pero hasta ahora ninguna me ha ayudado mucho. Originalmente estaba ejecutando Crucible en una caja de Windows con 2GB de RAM usando el HSQL DB incorporado. Pasar a MySQL en CentOS experimentó un aumento en el rendimiento de algunos repositorios e hizo que Crucible fuera mucho más estable, pero no pareció ayudar mucho con nuestro repositorio más grande. Solo hay tantos archivos / ramas que puedo excluir de la indexación mientras mantengo la utilidad de la herramienta.

Siendo ese el caso, ¿alguien tiene algún consejo sobre cómo acelerar Crucible en repositorios grandes, sin invertir en hardware increíblemente poderoso?

¡Gracias!

Editar: para aclarar, ya que no lo mencioné explícitamente arriba, estoy usando FishEye.

Edición 2: desde que publiqué esto originalmente, el rendimiento ha mejorado un poco con los nuevos lanzamientos de Crucible, pero aún así no es excelente. Parece que este problema afecta a muchos usuarios , incluidos algunos con hardware mucho más potente que el que estamos utilizando. Por lo tanto, no creo que sea un problema de hardware, sino más bien un problema con ineficiencia inherente en Crucible. Atlassian es consciente del problema e incluirá más mejoras de rendimiento en futuras versiones, por lo que esperamos que esos cambios resuelvan nuestros problemas.

Edición 3: había olvidado cuánto tiempo atrás había hecho esta pregunta, por lo que en mi edición anterior no mencioné que nuestra situación de hardware también ha cambiado desde que se hizo originalmente. Ahora estamos ejecutando Crucible en un servidor físico dedicado, que todavía usa CentOS. El hardware sigue siendo modesto (4 GB de RAM, CPU de cuatro núcleos y discos duales de 500 GB en RAID 1 con respaldo externo), pero vimos un ligero aumento en el rendimiento cuando nos alejamos de la VM.

svn fisheye crucible Mitch Lindgren
fuente
Sé que esta es una vieja pregunta, pero para su información, para cualquiera que encuentre esto a través de la búsqueda, en mi experiencia reciente (muy limitada) solo mover la base de datos a una instancia externa de PostgreSQL le dará una mayor velocidad para repositorios grandes (obviamente, esto supone que la máquina es lo suficientemente potente como para ejecutar una instancia de postgres de tamaño decente; también modifiqué un poco la configuración de vaccume para mi hardware, pero recién salido de la caja fue más rápido). Esto reducirá drásticamente los tiempos de acceso al disco, y el rendimiento y la usabilidad son mucho mejores que mysql (o al menos, parece ser para fecru)
Sam Whited

Respuestas:

2

Dado que la migración a MySQL marcó una diferencia notable para algunos repositorios, considere ajustar la base de datos para mejoras adicionales. Cambiar algunos my.cnfvalores de los valores predeterminados puede hacer una gran diferencia. Consulte Conceptos básicos de optimización del rendimiento de InnoDB para obtener más información. También verifique si hay consultas lentas habilitando el registro de consultas lentas y agregue índices cuando corresponda.

Mi próxima suposición sería la velocidad de la red: ¿está su instancia de Crucible en la misma red local cableada que sus repositorios SVN? También puede intentar darle a Crucible una ejecución de prueba en la misma máquina que su repositorio principal si es posible para eliminar la latencia de red como el culpable.

Y sé que puede ser difícil dependiendo de su entorno de trabajo, pero ejecutar Crucible en una VM probablemente no esté ayudando; Atlassian toma nota de esto en su muy breve página de Mejores prácticas para la configuración del crisol . Estoy seguro de que ya lo ha encontrado, pero también mencionaré la página Tuning FishEye para otros lectores.

También tengo problemas de rendimiento para proyectos grandes, pero atribuyo mucha lentitud a la interfaz web pesada de Crucible. Esto es especialmente cierto después de hacer clic un poco (las páginas vistas anteriormente en una revisión permanecen en la ventana del navegador, incluso cuando están ocultas). Nuestros desarrolladores han notado un ligero aumento de velocidad al cambiar a Google Chrome. Consulte también el Atlassian IDE Connector si existe un complemento compatible para su entorno de desarrollo. El conector Eclipse IDE tuvo sus propios problemas la última vez que lo usé (hace muchos meses), pero al menos podía manejar grandes conjuntos de archivos sin colgar.

Dependiendo de las prácticas de desarrollo de su empresa, podría dejar de escanear una gran cantidad de ramas de código (suponiendo que muchas de ellas ya no estén activas) y deshabilitar los repositorios para proyectos completados / muertos hasta que sean necesarios. Mi empresa utiliza equipos muy pequeños en una gran cantidad de proyectos, por lo que la mayoría de las veces trabajamos principalmente trunk, lo que hace que las sucursales sean la excepción; Por lo tanto, agregamos explícitamente ramas para escanear en lugar de incluir todas las ramas de forma predeterminada. También asegúrese de no escanear accidentalmente las etiquetas.

¿Cómo es el uso de tu CPU en la caja Crucible? Si está utilizando SVN detrás de Apache HTTPD, examine cuántas conexiones consume Crucible durante una exploración de repositorio grande. Aparte de eso, no estoy seguro de qué más podría mirar (¿tal vez la velocidad del disco? ¿Frecuencia de exploración del repositorio?), Pero espero que los consejos anteriores le ayuden un poco.

Dave
fuente
Gracias por la respuesta detallada. Actualicé mi pregunta original porque olvidé incluir información actualizada de hardware en mi edición anterior. La velocidad de la red es probablemente un problema en la indexación inicial, pero no debería causar problemas una vez que se han creado los índices (que es donde vemos mucho dolor, al examinar archivos indexados). Terminamos moviendo Crucible a una caja física dedicada y vimos Un modesto aumento del rendimiento. La mayoría de nuestros desarrolladores usan Chrome, y he advertido a todos que usan Crucible que NO usen IE como su motor JavaScript (antes de IE9 de todos modos) es muy lento.
Mitch Lindgren
No sabía que los archivos vistos anteriormente se guardaban en la memoria, así que me aseguraré de decirles a todos que actualicen cuando las cosas se pongan lentas. Para su información, sin embargo, Atlassian ha abandonado por completo el soporte para el conector Eclipse, del que recibí muchas quejas. Tienen conectores para otros IDEs, pero Eclipse es muy importante para nosotros. En cuanto a las sucursales, algunos de nuestros equipos no las usan y otras lo hacen ampliamente. Los equipos que no usan sucursales están bien. Los equipos que sí encuentran lentitud seria. Desafortunadamente, pedirles que cambien su proceso está fuera de discusión.
Mitch Lindgren
He examinado el rendimiento de MySQL anteriormente y lo volveré a hacer. Sin embargo, parece que el gran cuello de botella solo atraviesa los archivos de índice. Un disco más rápido podría ayudar aquí, pero nuestros discos ya son bastante rápidos (aunque no sean de primera línea. Antes de mudarme al nuevo servidor vi que esperaba mucho IO, pero ya no veo demasiado). Creo Todo lo que puedo hacer ahora es esperar las mejoras de rendimiento de Atlassian. Sin embargo, voy a marcar su respuesta como aceptada, ya que creo que contiene mucha información valiosa para otros que podrían estar en la misma situación.
Mitch Lindgren
1

> 4 G de RAM no son hardware "increíblemente poderoso". Suponiendo que tiene 25 usuarios y que está utilizando Fisheye (que usted menciona), está gastando $ 4400 solo en el software. $ 4k en Dell podría comprarle un servidor con 48G de RAM.

Además, ¿está utilizando una JVM de 64 bits? Los documentos sugieren que verá una mejor huella de memoria (como en menos) en una JVM de 32 bits.

Bill Weiss
fuente
Gracias por la info. Estamos utilizando una JVM de 64 bits. Veré si puedo cambiar a 32 bits y ver si ayuda. Editar: ¡Vaya! Presiona enter y guardó mi comentario en lugar de agregar nuevas líneas. Culpa mía. Con respecto al hardware, es algo así como un obstáculo: la situación del hardware está algo fuera de mi control, y es difícil para mí justificar un mayor gasto hasta que sepamos que la herramienta funcionará para todos los equipos que necesitan usarla. Veré si se puede hacer algo en la configuración existente (asigne más memoria a esa VM, por ejemplo).
Mitch Lindgren
Disculpas por hacer doble comentario, pero otra pregunta: ¿estás seguro de que la memoria es el problema? Me doy cuenta de que 4GB no es mucho, pero Fisheye / Crucible ni siquiera están maximizando el máximo de 3GB que he establecido en la JVM.
Mitch Lindgren
No estoy seguro si ese es tu problema, pero solo estaba señalando que eso no es "increíblemente poderoso". Si bien funciona mal, ¿podría recopilar algunas estadísticas del sistema? Corre top, iostaty todo lo demás, y mira qué duele.
Bill Weiss
"Increíblemente poderoso" era una mala elección de palabras. Simplemente siento que un servidor de $ 4,000 con 48 GB de RAM es un requisito excesivo para una aplicación web que utilizan tan pocos desarrolladores.
Mitch Lindgren
3
$ 4400/25 usuarios / 2 años == $ 88 / dev / año. ¿Cuántas horas de desarrollo al año tiene que salvarte?
Bill Weiss
0

Aunque en realidad no lo he intentado, estoy experimentando exactamente los mismos síntomas que tú.

Actualmente estoy considerando desactivar la información de diferencias almacenada para los repositorios ofensivos. Hice la pregunta en el sitio de preguntas y respuestas de Atlassian y obtuve algunos consejos prometedores.

Mi problema es el mismo: la indexación no es el problema, es una gran huella de disco que se ejecuta en una matriz de discos de bajo rendimiento en una máquina virtual. Como no puedo actualizar el disco en este momento, necesito encontrar otra forma de evitarlo. El que responde en mi publicación anterior dice que eliminar la información de diferencias reducirá la huella del disco a expensas de perder la capacidad de buscar líneas agregadas / eliminadas . Aunque también sugiere que no afectará la velocidad de exploración de archivos con historiales largos.

Si alguien más ve esto y puede informar el éxito / fracaso con este interruptor, comente aquí.

Ah, y estoy ejecutando 2.7.13 con los mismos problemas de rendimiento.

Mark McDonald
fuente