performance - tutorial - svn no es una copia de trabajo

Rendimiento de SVN después de muchas revisiones

Question

Mi proyecto actualmente usa un repositorio svn que gana varios cientos de revisiones nuevas por día. El repositorio reside en un servidor Win2k3 y se sirve a través de Apache / mod_dav_svn.

Ahora temo que con el tiempo el rendimiento se degradará debido a demasiadas revisiones.
¿Es este miedo razonable?
Ya estamos planeando actualizar a 1.5, por lo que tener miles de archivos en un directorio no será un problema a largo plazo.

Subversion almacena el delta (diferencias), entre 2 revisiones, por lo que ayuda a ahorrar MUCHO espacio, especialmente si solo ingresas código (texto) y no binarios (imágenes y documentos).

¿Eso significa que para ver la revisión 10 del archivo foo.baz, svn tomará la revisión 1 y luego aplicará los deltas 2-10?

Answer 1

¿Qué tipo de repo tienes? ¿FSFS o BDB?

(Supongamos FSFS por ahora, ya que es el predeterminado).

En el caso de FSFS, cada revisión se almacena como una diferencia con respecto a la anterior. Entonces, uno pensaría que sí, después de muchas revisiones, sería muy lento.

Sin embargo, este no es el caso. FSFS usa lo que se denomina "deltas de salto" para evitar tener que hacer demasiadas búsquedas en las revoluciones anteriores.

(Entonces, si usa un repositorio de FSFS, la respuesta de Brad Wilson es incorrecta).

En el caso de un repositorio de BDB, la revisión HEAD (última) es de texto completo, pero las revisiones anteriores se crean como una serie de diferencias frente a la cabeza. Esto significa que las revoluciones previas deben volver a calcularse después de cada confirmación.

Para más información: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

PD Nuestro repositorio es de aproximadamente 20 GB, con aproximadamente 35,000 revisiones, y no hemos notado ninguna degradación del rendimiento.

Answer 2

Estamos ejecutando un servidor de subversión con un valor de gigabytes de código y binarios, y hay más de veinte mil revisiones. Sin ralentizaciones aún.

Answer 3

Las únicas operaciones que pueden ralentizarse son las que leen información de múltiples revisiones (por ejemplo, SVN Blame).

Answer 4

No creo que nuestra subversión se ralentice por el envejecimiento. Actualmente tenemos varios TeraBytes de datos, principalmente binarios. Pagamos / comprometemos diariamente hasta 50 Gigabytes de datos. En total tenemos actualmente 50000 revisiones. Estamos utilizando FSFS como tipo de almacenamiento y estamos interactuando directamente con SVN: (Servidor Windows) o mediante Apache mod_dav_svn (Servidor Gentoo Linux).

No puedo confirmar que esto haga que svn se ralentice con el tiempo, ya que configuramos un servidor limpio para la comparación de rendimiento con el que podríamos comparar. No podríamos medir una degradación significativa.

Sin embargo, tengo que decir que nuestra subversión es extraordinariamente lenta por defecto y, obviamente, es la subversión en sí misma, como hemos intentado con otro sistema informático.

Por alguna razón desconocida, la subversión parece estar completamente limitada a la CPU del servidor. Nuestras tarifas de pago / confirmación están limitadas a entre 15-30 MegaBytes / s por cliente, porque entonces el núcleo de la CPU de un servidor se agota por completo. Esto es lo mismo para un repositorio casi vacío (1 GigaByte, 5 revisiones) como para nuestro servidor completo (~ 5 TeraByte, 50000 revisiones). Ajustar como configurar la compresión a 0 = apagado no mejoró esto.

Nuestro alto ancho de banda (entrega ~ 1 GigaByte / s) FC-Array está inactivo, los otros núcleos inactivos y de red (actualmente 1 GigaBit / s para clientes, 10 GigaBits / s para el servidor) están inactivos también. Está bien, no realmente al ralentí, pero si solo se utiliza el 2-3% de la capacidad disponible, lo llamo "ralentí".

No es realmente divertido ver todos los componentes al ralentí y debemos esperar a que se revisen o completen nuestras copias de trabajo. Básicamente no tengo idea de lo que está haciendo el proceso del servidor al consumir completamente un núcleo de la CPU todo el tiempo durante la verificación / confirmación.

Sin embargo, solo estoy tratando de encontrar una forma de ajustar la subversión. Si esto no es posible, podríamos necesitar cambiar a otro sistema.

Por lo tanto: Respuesta: No SVN no se degrada en el rendimiento, inicialmente es lento.

Por supuesto, si no necesita un rendimiento (alto), no tendrá ningún problema. Por cierto. todo lo anterior se aplica a subversioon 1.7 última versión estable

Answer 5

No estoy seguro ... Estoy usando SVN con apache en Centos 5.2. Funciona bien El número de revisión era 8230 algo así ... Y en todas las máquinas cliente, Commit fue tan lento que tuvimos que esperar al menos 2 minutos para obtener un archivo de 1kb. Estoy hablando de 1 archivo que no tiene gran tamaño de archivo.

Luego hice un nuevo repositorio. Comenzó desde rev. 1. Ahora funciona bien. Rápido. utilizado svnadmin create xxxxxx. no verifico si es FSFS o BDB .....

Answer 6

Personalmente, no he tratado con repositorios Subversion con bases de código mayores que 80K LOC para el proyecto real. El repositorio más grande que he tenido realmente fue de aproximadamente 1,2 gigas, pero esto incluía todas las bibliotecas y utilidades que usa el proyecto.

No creo que el uso diario se vea tan afectado, pero todo lo que necesite revisar las diferentes revisiones podría ralentizarse un poco. Puede que ni siquiera sea notable.

Ahora, desde el punto de vista del administrador del sistema, hay algunas cosas que pueden ayudarlo a minimizar los cuellos de botella de rendimiento. Como Subversion es principalmente un sistema basado en archivos, puede hacer esto:

• Coloque los repositorios reales en una unidad diferente
• Asegúrese de que ninguna aplicación de bloqueo de archivos, a excepción de svn, esté trabajando en la unidad anterior
• Haga las unidades al menos 7,500 RPM. Podría intentar obtener 10,000 RPM, pero puede ser exagerado
• Actualice la LAN a gigabit, si todos están en la misma oficina.

Esto puede ser excesivo para su situación, pero eso es lo que he hecho habitualmente para otras aplicaciones que utilizan muchos archivos.

Si alguna vez "superas" Subversion, entonces Perforce será tu próximo paso. Es sin dudas la aplicación de control de código fuente más rápida para proyectos muy grandes.

Answer 7

Subversion almacena la versión más reciente como texto completo, con diferencias hacia atrás. Esto significa que las actualizaciones para encabezar siempre son rápidas, y lo que paga incrementalmente se está viendo cada vez más atrás en la historia.

Answer 8

Subversion solo almacena el delta (diferencias), entre 2 revisiones, por lo que esto ayuda a ahorrar MUCHO espacio, especialmente si solo ingresas código (texto) y no binarios (imágenes y documentos).

Además, he visto muchos proyectos muy grandes usando svn y nunca me he quejado por el rendimiento.

¿Tal vez te preocupan los horarios de pago? entonces supongo que esto realmente sería un problema de red.

Ah, y he trabajado en repositorios de CVS con 2Gb + de cosas (código, imgs, documentos) y nunca tuve un problema de rendimiento. Como svn es una gran mejora en cvs, no creo que deba preocuparse.

Espero que ayude a su mente un poco más fácil;)

Answer 9

Tal vez deberías considerar mejorar tu flujo de trabajo.

No sé si un repos tendrá problemas de rendimiento en estas condiciones, pero su capacidad para volver a una revisión sensata sí lo hará.

En su caso, es posible que desee incluir un proceso de validación, de modo que un equipo se comprometa en un repositorio de líder de equipo, y cada uno de ellos se comprometa con el repo del gerente de equipo que se compromete con los repositorios de limpieza de la empresa de solo lectura. Ha hecho una selección limpia en la etapa de qué compromiso debe ir a la cima.

De esta forma, cualquiera puede volver a una copia limpia, con un historial fácil de explorar. La fusión es mucho más fácil, y el dev puede seguir cometiendo su desastre tanto como lo deseen.