¿Cuánta RAM necesita realmente un servidor?

Tengo bastantes servidores implementados en todo el mundo. Están ejecutando Windows 2003 x64 con SQL Server 2005 x64 con 6 GB de RAM. Las cajas no tienen la mejor (o incluso una configuración aceptable), porque el tipo que las ordenó hace años realmente no sabía lo que estaba haciendo.

Los cuadros se están quedando sin memoria de manera bastante consistente, terminan usando el archivo de paginación y todo se ralentiza. Normalmente, el cargo de confirmación es de 5,8 GB y luego, cuando alguien necesita hacer algo intensivo (por ejemplo, ejecutar un informe), ese número se dispara.

He estado tratando de obtener los poderes necesarios para ordenar más memoria, pero estoy obteniendo una oposición masiva (por ejemplo, hacer que el software sea más eficiente, cuesta demasiado para todos estos servidores, o pruebo que la caja no tiene suficiente memoria, etc. ..).

¿Existen pautas (o una fórmula) para la cantidad de RAM que necesita una caja que pueda presentar a los no técnicos, para que finalmente podamos ordenar más memoria?

Realmente no hay forma de saberlo fácilmente porque depende completamente de su uso y la aplicación. Estás maximizando un servidor de base de datos ... ¿qué tamaño tiene la base de datos? ¿Cuáles son sus estadísticas de transacción?

Las limitaciones del mundo real son obvias en su escenario. Estás corriendo por un tiempo en 6 conciertos sin problema, luego se intercambia y se agita, por lo que 6 conciertos no son suficientes.

Si el rendimiento es suficiente para afectar el negocio, entonces sus superiores deberían estar escuchando suficientes quejas de que es prudente aumentar la memoria. Calcule cuánto cuesta su tiempo y luego cuánto costará "sintonizar" el servidor y solucionar los problemas de ajuste, cuando la memoria agregada al servidor puede resolver el problema por el costo de la memoria y menos de media hora de falta del tiempo.

No sabrá la cantidad exacta de memoria que necesita hasta que realmente se implemente en su uso de la vida real y trabaje desde allí.

Dicho esto, es posible que desee verificar que su aplicación sea realmente el cuello de botella. Ejecute el monitor de rendimiento de Windows para ver las estadísticas de E / S del disco y el rendimiento de la red. Vea también cuál es su nivel de fragmentación ( Google es un buen amigo aquí ). También puede intentar auditar el código en busca de problemas obvios en los que una consulta sea enormemente ineficiente ( Google nuevamente ).

Pero, de nuevo, todo depende de cuán gravemente esto esté afectando al negocio. ¿Vale la pena invertir más en el ajuste, o es lo suficientemente malo como para lanzarle hardware primero y luego intentarlo?

Una manera fácil de ver si necesita más RAM es trazar el contador de rendimiento de Page Life Expectancy. Este contador le indica cuánto tiempo SQL Server piensa que los datos se mantendrán en el grupo de búferes antes de que necesite dejar espacio para otros datos. Desea este número lo más alto posible. Con 6 Gigas de RAM instaladas (debe tener SQL configurado para un máximo de probablemente 4 gigas) probablemente solo mantendrá los datos en la memoria durante unos minutos como máximo, cuando alguien ejecute un informe grande verá este tanque de números hasta unos segundos Cuanta más memoria RAM tenga, más datos se pueden guardar en la memoria y menos lecturas de los discos deberán realizarse.

Por ejemplo, los sistemas con los que estoy trabajando en este momento tienen 256 Gigs de RAM y mantenemos los datos en la memoria durante aproximadamente 12000 segundos más o menos.

No solicite un número objetivo para golpear, solo desea que el número sea lo más alto posible. Sin saber MUCHO más sobre sus sistemas, no puedo dar un buen número para disparar.

Hmmmm Bueno, 6 gigas es una cantidad decente de RAM, incluso para una gran instalación de MSSQL. Es posible que desee mirar y asegurarse de que su código sea realmente eficiente. Una transacción de 6 conciertos es un poco inusual ... He trabajado en sistemas de nómina en todo el estado que no superaron un concierto en el procesamiento de fin de año 1099 ... ¿Y tener uno funcionando a menudo ? No lo sé. ¿Con qué tipo de datos estás trabajando?

Una vez dicho esto, puede almacenar tanta RAM como desee en una caja de 64 bits, y el ram es muy barato, por lo que podría poner tanto como sea posible ... Realmente no puede tener demasiada RAM en Un servidor de base de datos.

Editar: Esto está muy desactualizado ahora. Tengo cajas MSSQL con 256 gigas de RAM.

Antes de comenzar a comprar más memoria (o cualquier otro componente), recomendaría ejecutar un análisis de rendimiento en el servidor. Puede hacerlo por su cuenta usando perfmon o puede mirar usando herramientas de terceros. Debe analizar el rendimiento tanto del sistema operativo como del servidor SQL. En mi humilde opinión, con demasiada frecuencia estamos listos para lanzar hardware a un problema antes de que se haya realizado un análisis adecuado. Por lo que sabe en este momento, podría ser un problema con una consulta, procedimiento almacenado, plan de ejecución, E / S de disco, utilización de CPU, etc., etc. La presión de la memoria a menudo puede ser un síntoma de otro cuello de botella en el sistema.

como dijo "Satanicpuppy", no hay demasiada RAM, pero 6GB deberían estar bien, tal vez deberías repensar lo que hace tu servidor, no creo que tengas un problema de "hardware", deberías enfóquese en su programación SQL ...

Cuando se trata de servidores de bases de datos, no existe una memoria "suficiente". Claro, depende de lo que realmente hacen y ejecutan, pero si se trata de una base de datos constantemente utilizada que contiene una gran cantidad de datos y hace consultas complicadas, 6 GB podrían ser muy inadecuados.

Comenzaría por actualizar un servidor problemático a al menos 32 o 64 GB y ver si ayuda. De lo contrario, recurra al ajuste de la base de datos, la resolución de problemas y la depuración de la aplicación, que, a menos que un idiota diseñó la base de datos, cuesta mucho más que unos pocos pedazos de memoria de nivel de servidor (e incluso si un idiota diseñó la cosa, obteniendo incluso un diseño obvio los errores solucionados con soporte retenido podrían ser un gran desafío).

Dicho esto, como dijo alguien más: podría ser algo más que lo frene (aparte de los problemas de diseño de software), como la falta de rendimiento de E / S de disco o red: contratar a un profesional de DBA para que solo realice la supervisión básica del rendimiento de SQL para El día podría resultar útil.

Deberías buscar construir más índices. Creo que, en general, la mayoría de las personas subindice su base de datos.

Esto todavía es código aéreo, aún no lo he probado completamente, pero debería llevarlo en la dirección correcta

http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100