... esperaba poder obtener ... una estimación aproximada de lo que deberíamos estar ejecutando.
Sin más información sobre sus consultas y tamaños de datos, es realmente difícil darle cualquier tipo de estimación, y mucho menos una estimación precisa.
Base de datos: base de datos empresarial sql server 2008 r2
Windows: Windows 2008 r2 Enterprise de 64 bits, bastante seguro que se ejecuta en VMware.
Procesador: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 procesadores)
Memoria instalada: 4 GB
Dos procesadores (supongo que esto está expuesto en la máquina virtual como 2 núcleos) pueden o no tener un aprovisionamiento insuficiente. Los núcleos asignados a una VM no están necesariamente asignados directamente a núcleos físicos (¡o incluso se les permite usar el 100% de un solo núcleo cuando sea necesario!), Por lo que puede encontrar que este es un recurso más flexible que la memoria. Sin más información sobre su carga de trabajo o configuración de hardware / virtualización, diría que aumentar esto a 4 sería bueno.
Asignación de memoria. Oh chico. Esto está muy poco aprovisionado para la carga de trabajo. Windows mismo necesita un mínimo de 2-3 GB para mantenerse feliz, y cada uno de los 2 usuarios que ejecutan BIDS en la caja requerirá al menos 500 MB cada uno. Y con eso, el cuadro ya está al máximo, y ni siquiera comencé a calcular cuánto va a necesitar la base de datos .
La mayoría de los usuarios interactúan con la base de datos a través del sitio web asp.net y el sitio web del servidor de informes.
No lo dijo, pero si estos se ejecutan en el mismo cuadro, los requisitos de memoria para ellos también deben tenerse en cuenta.
Finalmente, tenemos una operación de almacenamiento de datos bastante complicada que probablemente trae 3 millones de registros por día a través de paquetes SSIS que también se ejecutan en el servidor.
Suponiendo que esto se ejecuta por la noche cuando no hay usuarios en vivo en el sistema, no veo esto como un problema a menos que tarde demasiado en ejecutarse. Esta parte de las cosas es la menor de tus preocupaciones; Los usuarios en vivo son más importantes.
Nuestras solicitudes anteriores de memoria adicional se han denegado con la respuesta común de que necesitamos realizar más optimizaciones de consultas.
Como demostré anteriormente, la cantidad actual de memoria aprovisionada es completamente inadecuada. Al mismo tiempo, sin embargo, en el otro extremo del espectro, es extremadamente improbable que pueda obtener suficiente memoria aprovisionada para poder mantener toda la base de datos en la memoria a la vez.
Aunque recibió una respuesta general como esa (que, por cierto, probablemente tuvo más que ver con lo persuasiva que era su justificación de recursos adicionales, y no con el uso real de los recursos en sí), es muy probable que la eficiencia de la base de datos pueda ser mejorado. Sin embargo, no hay una cantidad de ajuste solo que pueda solucionar los problemas que está experimentando ahora; la sugerencia de eso es un completo no iniciador para mí.
Adoptaría el enfoque general de que la cantidad de memoria aprovisionada actualmente está por debajo del mínimo requerido (que debe corregirse lo antes posible), y se pueden requerir recursos adicionales para mejorar la experiencia del usuario a un nivel utilizable mientras se realizan mejoras para aumentar la eficiencia de los sistemas
Aquí hay algunos pensamientos (en orden de ataque):
Va a ganar si se puede probar cuánto rendimiento mejora cada vez que reciba más recursos aprovisionados. Realice un seguimiento de las métricas de rendimiento utilizando el registro de Monitor de rendimiento (nota: la parte de registro es muy importante), incluidos los tiempos de respuesta del sitio web si puede. Comience a hacer esto ahora , antes de hacer cualquier otra cosa. Cuando finalmente llegue a la cantidad mínima de memoria (no obtendrá 32 GB de inmediato), de repente ahora tiene evidencia de que la memoria agregada mejoró las cosas ... ¡lo que significa que agregar aún más probablemente también ayude! Si no recopila una línea de base en la configuración actual, perderá el bote cuando las cosas suban al nivel mínimo recomendado.
Analiza las estadísticas de espera de tu servidor . Esto le dirá cuál es el mayor cuello de botella en el sistema. Probablemente tendrá PAGEIOLATCH_XXel tiempo de espera más común / más alto, lo que indica que se está haciendo demasiada E / S para recuperar páginas del disco. Esto se puede aliviar agregando memoria, por lo que las E / S físicas se vuelven menos frecuentes ya que los datos necesarios ya están en la memoria. Si bien este análisis es prácticamente una conclusión inevitable, el hecho de que haya recopilado estas estadísticas le brinda más munición al justificar la necesidad de recursos.
Como mencioné anteriormente, no se cumple el requisito mínimo básico de memoria. Recopile el conjunto de requisitos de hardware recomendados para todo el software que está ejecutando, y tal vez también tome capturas de pantalla del Administrador de tareas. Esto solo debería ser suficiente para justificar al menos 4-8 GB más, en el acto. Si todavía se niegan, intente convencerlos de que le permitan probarlo durante una semana y devuélvalo después de eso (está recopilando estadísticas de rendimiento, por lo que no tendrá que devolverlo porque a mediados de la semana usted ' podrá probar cuánto ha mejorado la situación). Si todavía se niegan, estás siendo configurado para fallar; URLT .
Si puede descargar parte de la carga de trabajo (en particular, evite la conexión remota si es posible), esto aumentará la cantidad de memoria disponible para la base de datos, lo cual es más crítico.
No podrá ajustar toda la base de datos en la memoria a la vez, lo que significa que debe establecer la configuración de memoria máxima de SQL Server con mucho cuidado para evitar el exceso de memoria , lo que mata el rendimiento como ninguna otra cosa . El exceso de compromiso es incluso peor que simplemente no poder ajustar todos los datos en la memoria. Es muy probable que esté en este escenario en este momento simplemente porque simplemente no hay memoria disponible en absoluto, y es probable que la configuración de memoria máxima esté establecida en el valor predeterminado (ilimitado).
Como está ejecutando SQL Server Enterprise Edition y la memoria es muy importante, consideraría implementar la compresión de datos . Esto compensará un aumento en el uso de la CPU para ahorrar espacio en la memoria (y, por lo tanto, reducir los accesos al disco, que son comparativamente muy lentos).
Ajusta la base de datos. Es probable que las estructuras y consultas puedan usar mejoras en lo que respecta a los patrones de indexación y acceso. Además, si se escanean y agregan muchos datos con frecuencia, puede ser muy útil crear vistas indexadas, tablas de resumen o informes precalculados.
Esto podría ser una posibilidad remota porque probablemente signifique más aprovisionamiento de hardware, pero implemente una solución de almacenamiento en caché. La consulta más rápida es la que nunca haces .
Esas son solo algunas ideas. La conclusión es que el ajuste solo no resolverá los problemas aquí, ni el hardware solo, aunque este último probablemente aliviará la mayoría de los problemas inmediatos. Así es como funciona: arroje el hardware al problema a corto plazo para apagar el fuego, y ajuste el problema a largo plazo para solucionar la causa raíz lo mejor que pueda.