Si le preguntaran si un sistema podría sostener un doble crecimiento, ¿qué 3 cosas haría para responder?

Question

Digamos que en tu trabajo tu jefe dice:

  

Ese sistema de allí, que ha perdido todo el conocimiento institucional pero parece funcionar bastante bien en este momento, ¿podríamos volcar el doble de datos y sobrevivir?

No está completamente familiarizado con el sistema.

Está en SQL Server 2000 (principalmente una aplicación de base de datos).

No hay entorno de prueba.

Es posible que pueda secuestrarlo los fines de semana si necesita ejecutar un punto de referencia.

¿Cuáles serían las 3 cosas que haría para convencerse a sí mismo y luego a su gerente de que podría asumir esa carga adicional? Y si no pudiera hacerlo, en el mismo hardware ... el hardware adicional (medido en dólares) que se necesitaría para satisfacer esa solicitud.

Para abordar la respuesta de doofledorfer, sus suposiciones están casi a 180 grados de distancia. Pero es mi culpa por una pregunta ambigua.

1. Uno de los servidores principales ejecuta 7x24 al 70% de base y se dispara desde allí y nadie sabe lo que está haciendo.

2. Esto no es un problema de aceptación o queja ... Es posible que nuestra empresa no tenga muchas opciones al respecto.

3. Debido a que esto tiene un mandato externo, los retrasos en la implementación podrían dar lugar a enormes multas. Tan grande reunión para evaluar el riesgo son casi imposibles. Existe un riesgo: que eliminar el doble de datos derribaría el sistema para los clientes existentes.

Esperaba que alguien dijera algo como, ver si desconecta el sistema el domingo por la noche a medianoche y ejecuta pruebas SQLIO para ver qué tan cerca está el subsistema de almacenamiento de la saturación. Cosas así.

Answer 1

1. Configure un entorno de prueba, incluso si tengo que hacerlo en mi computadora portátil.

2. Habilite algún tipo de inicio de sesión en el sistema de producción para tener una idea del volumen de transacciones además del volumen de datos.

3. Lea el código fuente mientras ejecuto pruebas de estrés en mi computadora portátil con cantidades cada vez mayores de datos.

Habiendo dicho eso, simpatizo con esta tarea, porque es injusto. Es como preguntarle a alguien en un bote si el bote puede flotar con el doble de carga, pero usted no puede salir del bote o sacarlo de su servicio regular.

Answer 2

Acaba de describir un proyecto Agile típico. Su respuesta debería ser:

1. No lo sé, y no podré saberlo sin probarlo.
2. Además del volumen de datos, puede haber problemas con los patrones de uso, las interacciones de las aplicaciones, el ajuste de la base de datos y del servidor, etc.
3. Entonces, analicemos una lista básica de factores de riesgo y cómo podemos resolverlos.
4. Una vez que hayamos hecho eso, analicemos en orden inverso de riesgo; y tomar una decisión de detener / continuar a medida que desarrollamos los resultados.
5. etc.

Sin la aceptación y participación de la gerencia al menos a ese nivel, cualquier otra respuesta que pueda dar es un deseo de alto riesgo, y "3 lo más importante". es un non sequitur.

Sería optimista a menos que su sistema actual ya esté sustancialmente cargado. La mayoría de los servidores deben ejecutarse a menos del 50% de la capacidad en todos los recursos, o de lo contrario estar en soporte vital. Y espero que no tenga la conversación si el servidor existente ya estuviera lidiando con problemas de carga; aunque "parece funcionar bastante bien en este momento" es lo suficientemente impreciso como para ser preocupante.

Answer 3

depende principalmente de su nivel actual. Si duplicar va de 2GB a 4GB, simplemente hágalo. Si va de 1TB a 2TB, tiene algo que planear hacer.

Recopilaría información con el Monitor de rendimiento y la proporcionaría para ayudar a tomar una decisión informada.

Answer 4

Depende de lo que quiera decir con "duplicar los datos".

Si eso va a afectar solo a una tabla (por ejemplo, tabla de productos), entonces es probable que esté seguro ya que la mayoría de las consultas que se refieren a esa tabla tienen más probabilidades de duplicar el tiempo de ejecución (eso supone que no hace referencia a la tabla mismo tiempo dos veces en una consulta).

El problema surgirá si duplica la cantidad de datos en todas las tablas, ya que el tiempo de ejecución puede crecer de manera exponencial y puede conducir a algunos problemas graves.

Pero en general apoyaría el respuesta por doofledorfer