¿Cómo estimas cuánta memoria comprar?

Tengo una aplicación de servidor personalizada que se ejecuta en Windows 2008 R2. Es un servicio de Windows casero escrito en .Net que admite una serie de terminales personalizadas. Tengo una máquina de prueba que tiene una especificación similar al servidor en vivo y tengo un conjunto de simuladores de clientes que puedo usar para producir una carga que sea una aproximación razonable del sistema real. Necesito poder soportar 12,000 de estos y actualmente el servidor se está quedando sin memoria (la paginación está por las nubes).

Mi plan era comenzar solo 100 de los simuladores, medir el uso de la memoria, luego comenzar nuevamente 100 más medir la memoria y repetir hasta que la paginación comience a subir (en realidad tomaré más de tres puntos de datos). Esto debería darme una cifra para la cantidad de memoria adicional requerida para 100 simuladores y me permite proyectar cuánta memoria se requiere. Solo necesito una idea aproximada de +/- 30Gb para evitar comprar los 2Tb completos (valor de $ 150,000) que tomará el servidor. Mi pregunta es si este es un método razonable de usar y, de ser así, ¿qué contadores de rendimiento supervisaría para dar la cantidad de memoria que realmente se está usando?

Estoy hablando específicamente de memoria aquí, ya que la diferencia entre Conjunto de trabajo, Bytes privados, Comprometido, Compartido, Virtual y todos los demás términos de memoria me confunden. Creo que puedo controlar la CPU, las E / S y las redes yo solo. La otra cosa que he notado es que .Net Cache ajusta su uso de memoria dependiendo de lo que esté disponible, lo que hace que detectar una tendencia sea difícil de ver.

¿Honestamente? Yo no .
Cuando especifico un servidor que verá cualquier tipo de carga de trabajo real, acumulo la mayor cantidad de RAM que razonablemente puedo permitir (es más probable que los sistemas terminen con restricciones de RAM que con CPU o de disco; el único otro cuello de botella garantizado es la parte frontal autobús).

Si desea averiguar cuánta RAM puede usar su aplicación una prueba de carga básica como la que ha propuesto, es un buen comienzo, pero si ya tiene este sistema en producción (parece que sí) y su sistema de producción está cambiando su la tarea es más fácil: calcule cuánto espacio de intercambio está utilizando -> Agregue al menos 2 veces esa cantidad de RAM (redondee para ajustarse a las restricciones de tamaño DIMM de su sistema).

Si realiza una prueba de carga para obtener números aproximados y extrapolar desde allí, recuerde tener en cuenta algunas cosas:

1. La curva de memoria probablemente será de dos segmentos distintos
   (aumento agudo inicial a medida que se almacenan en caché los frameworks / bibliotecas compartidas, luego una curva ligeramente menos pronunciada a medida que el código no compartible de cada nueva aplicación se guarda en la memoria)

2. Todavía necesita RAM libre para el almacenamiento en caché del disco y la biblioteca compartida, y para el sistema operativo.
   (Esto debería ser al menos algunos conciertos sobre lo que necesita su aplicación)

3. TODO el software pierde memoria (al menos todo el software práctico lo hace), así que esté atento a eso en sus pruebas y asegúrese de tener espacio para lidiar con una fuga.

4. Su carga probablemente aumentará durante la vida útil del servidor. Planificar en consecuencia.
   (Si no tiene buenos números de planificación de capacidad, duplique la carga de trabajo de hoy y planee manejar eso).

5. Comprar demasiada RAM hoy es más barato que hacer que su entorno se caiga mañana.

   • Primer corolario: si compra un servidor un poco más grande de lo que necesita, es el administrador profético que mantuvo la empresa en funcionamiento. Serás ampliamente ignorado y no apreciado.
   • Segundo corolario: si subestima la máquina y hay problemas, es un bufón incompetente que no podría anticipar un crecimiento del 500% y todos lo odian.

Gracias, la actualización al menos les da a todos una pista. Que esté contemplando 2Tb de memoria significa que está jugando en un estadio diferente a las configuraciones habituales. Gran sistema Odio pensar cuánto calor va a estar apagando.

Dado que es un proceso interno del servidor y que se está quedando sin memoria (no dice a qué nivel comienza a paginar), pero me gustaría eliminar la posibilidad de que el proceso del servidor consuma cantidades cada vez mayores de memoria antes de continuar más lejos. Si esto ocurre, no importa lo que haga, el sistema se detendrá en algún momento.

No conozco ninguna herramienta genérica que pueda usar para brindarle mucho más que una descripción básica de lo que está sucediendo ... lo que viene con Windows. El proceso de servicio en sí es un cuadro negro y su equipo de desarrollo debe proporcionar herramientas de monitoreo.

Regreso rápido del cálculo del sobre

2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session

Esto no estaría fuera del rango de un conjunto de trabajo normal de .NET exe.

¿El servicio tiene múltiples hilos? Si están lanzando un hilo para cada conexión, valdría la pena ver cómo lo están haciendo. ProcExp.exe de microsoft es una manera fácil de ver si tiene varios subprocesos y qué están consumiendo esos subprocesos. No sabe acerca de .net, pero le dará contadores win32.

¿Puede indicar cuánta memoria y cuántas conexiones tenía al hacer sus pruebas antes de que comenzara la búsqueda?

Entonces, ¿cómo establecer si el proceso del servidor tiene problemas de pérdida de memoria? Podría estar acumulando más memoria con cada sesión conectada, o podría estar acumulando memoria y no liberándolos nunca.

Lo que puede hacer es elegir una cantidad de sesiones que no provoque la búsqueda y simular esa cantidad de conexiones. - Ejecute la simulación durante unas pocas horas y use perfmon para ver los contadores de memoria básicos. - Repita estas pruebas con sesiones que se conectan brevemente y se desconectan.

La idea es ver si el servicio consume más y más memoria con cada sesión, o si las sesiones abiertas provocan un uso cada vez mayor de la memoria.