Rendimiento de SVN después de muchas revisiones

Question

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

Ahora me temo que, con el tiempo, el rendimiento se degradará debido a demasiadas revisiones.
¿Es este temor 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 esto ayuda a ahorrar MUCHO espacio, especialmente si solo confirma código (texto) y no binarios (imágenes y documentos).

¿Eso significa que para revisar 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 ese es el valor predeterminado).

En el caso de FSFS, cada revisión se almacena como un diferencial frente a la anterior. Entonces, pensarías que sí, después de muchas revisiones, sería muy lento.

Sin embargo, este no es el caso. El FSFS usa lo que se llama " omitir deltas " para evitar tener que hacer demasiadas búsquedas en las revisiones anteriores.

(Por lo tanto, si está utilizando un repositorio de FSFS, la respuesta de Brad Wilson es incorrecta).

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

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

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

Answer 2

Subversion almacena la versión más actual como texto completo, con diferencias hacia atrás. Esto significa que las actualizaciones a la cabeza siempre son rápidas, y lo que pagas de forma incremental se ve cada vez más atrás en la historia.

Answer 3

Personalmente, no he manejado los repositorios de Subversion con bases de código más grandes que 80K LOC para el proyecto real. El repositorio más grande que he tenido en realidad fue de aproximadamente 1.2 gigas, pero esto incluyó todas las bibliotecas y utilidades que usa el proyecto.

No creo que el uso diario se vea afectado tanto, pero cualquier cosa que necesite revisar las diferentes revisiones puede ralentizarse un poco. Puede que ni siquiera se note.

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

• Coloque los repositorios reales en una unidad diferente
• Asegúrese de que no haya aplicaciones de bloqueo de archivos, aparte de svn, que funcionen en la unidad anterior
• Haga que las unidades tengan al menos 7,500 RPM. Puede intentar obtener 10,000 RPM, pero puede ser una exageración.
• Actualice la LAN a gigabit, si todos están en la misma oficina.

Esto puede ser una exageración para tu situación, pero eso es lo que normalmente hago para otras aplicaciones de uso intensivo de archivos.

Si alguna vez " supera " Subversion, entonces Perforce será su próximo paso adelante. Es indiscutiblemente la aplicación de control de fuente más rápida para proyectos muy grandes.

Answer 4

Estamos ejecutando un servidor de subversión con gigabytes de código y binarios, y tiene más de veinte mil revisiones. No hay ralentizaciones todavía.

Answer 5

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

Además, he visto muchos proyectos muy grandes usando svn y nunca me quejé del rendimiento.

¿Quizás te preocupen los horarios de pago? entonces supongo que esto realmente sería un problema de red.

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

Espero que te ayude un poco a tu mente;)

Answer 6

No creo que nuestra subversión disminuya con el envejecimiento. Actualmente tenemos varios TeraBytes de datos, en su mayoría binarios. Realizamos checkout / commit diariamente hasta 50 GigaByte de datos. En total tenemos actualmente 50000 revisiones. Estamos utilizando FSFS como tipo de almacenamiento y estamos interactuando directamente con SVN: (servidor de Windows) o mediante Apache mod_dav_svn (Gentoo Linux Server).

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 muy lenta por defecto y, obviamente, es la subversión en sí misma como lo intentamos con otro sistema informático.

Por algunas razones desconocidas, subversion parece estar completamente limitado por la CPU del servidor. Nuestras tasas de verificación / confirmación están limitadas a entre 15 y 30 MegaBytes / s por cliente porque entonces un núcleo de CPU del servidor está completamente agotado. 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 ajustar la compresión a 0 = desactivado no mejoró esto.

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

No es realmente divertido ver a todos los componentes inactivos y debemos esperar a que nuestras copias de trabajo se verifiquen o se procesen. Básicamente, no tengo idea de lo que está haciendo el proceso del servidor al consumir por completo un núcleo de CPU todo el tiempo durante el proceso de pago / confirmación.

Sin embargo, solo estoy tratando de encontrar una manera de ajustar la subversión. Si esto no es posible, es posible que tengamos que cambiar a otro sistema.

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

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

Answer 7

Las únicas operaciones que probablemente disminuyan la velocidad son las cosas que leen información de varias revisiones (por ejemplo, culpa de SVN).

Answer 8

No estoy seguro ... Estoy usando SVN con apache en Centos 5.2. Funciona bien El número de revisión fue 8230 algo así ... Y en todas las máquinas cliente, el compromiso 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ó a partir de rev. 1. Ahora funciona bien. Rápido. utiliza svnadmin crear xxxxxx. no comprobó si es FSFS o BDB ...

Answer 9

Tal vez debería considerar mejorar su flujo de trabajo.

No sé si los repositorios tendrán problemas de rendimiento en estas condiciones, pero la capacidad de volver a una revisión sana lo hará.

En su caso, es posible que desee incluir un proceso de validación, por lo que un equipo confíe en un repositorio del líder del equipo, y cada uno de ellos se comprometa con el representante del jefe de equipo que se comprometa con los repositorios de la empresa de solo lectura. Ha realizado una selección limpia en la etapa en la que el compromiso debe ir a la parte superior.

De esta manera, cualquiera puede volver a una copia limpia, con un historial fácil de navegar. Fusionar es mucho más fácil, y el desarrollador aún puede cometer su desorden tanto como ellos quieran.