rendimiento de SVN después de muchas revisiones

Question

Mi proyecto está utilizando actualmente 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.

subversión en las tiendas delta (diferencias), entre 2 revisiones, por lo que este ayuda a ahorrar mucho espacio, especialmente si sólo se compromete código (texto) y no hay 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 repositorio tienes? ¿FSFS o BDB?

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

En el caso de FSFS, cada revisión se almacena como un diff en contra de 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.

(Por lo tanto, si usted está usando un repo FSFS, la respuesta de Brad Wilson está mal.)

En el caso de un acuerdo de recompra de BDB, la cabeza (última) la revisión es de texto completo, pero las revisiones anteriores son construido como una serie de diffs contra 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

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 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 le preocupan las horas de salida? entonces supongo que esto realmente sería un problema de red.

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

creo que sirve fácil su mente un poco;)

Answer 3

Las únicas operaciones que puedan reducir la velocidad son cosas que leer la información de múltiples revisiones (por ejemplo SVN culpa).

Answer 4

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 5

Personalmente no he tratado con repositorios de Subversion con bases de datos 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 afectado en gran medida, pero todo lo que necesite ver a través de 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. Dado que Subversion es sobre todo un sistema basado en archivos, usted puede hacer esto:

• puso a los repositorios reales en una unidad diferente
• asegurarse de que ningún archivo de aplicaciones, aparte de SVN de bloqueo, están trabajando en la unidad por encima de
• Haga que las unidades tengan al menos 7.500 RPM.Podría tratar de obtener 10.000 RPM, pero puede ser excesivo
• Actualice la LAN a Gigabit, si todos están en la misma oficina.

Esto puede ser exagerado para su situación, pero eso es lo que he hecho habitualmente para otras aplicaciones de uso intensivo de archivos.

Si alguna vez "superas" a 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 6

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

Answer 7

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. svnadmin create create xxxxxx. no verificó si es FSFS o BDB .....

Answer 8

Quizás debería considerar la posibilidad de mejorar su flujo de trabajo.

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

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

De esta manera, 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.

Answer 9

No creo que nuestra subversión se haya ralentizado 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 del rendimiento que podí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 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 High Bandwith (entrega ~ 1 GigaByte/s) FC-Array inactivo, los otros núcleos inactivos y de red (actualmente 1 GigaBit/s para clientes, 10 GigaBits/s para el servidor) 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 funcionando al ralentí y tenemos que 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, estoy tratando de encontrar una manera 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, es inicialmente lento.

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