De combien de RAM un serveur a-t-il réellement besoin?

J'ai pas mal de serveurs déployés dans le monde. Ils exécutent Windows 2003 x64 avec SQL Server 2005 x64 avec 6 Go de RAM. Les boîtes n'ont pas la meilleure configuration (ou même une configuration acceptable), car le gars qui les a commandées il y a des années ne savait pas vraiment ce qu'il faisait.

Les boîtes manquent de mémoire assez régulièrement, finissent par utiliser le fichier d'échange et tout ralentit. En règle générale, les frais de validation sont de 5,8 Go, puis lorsque quelqu'un doit faire quelque chose d'intensif (par exemple, générer un rapport), ce nombre passe par le toit.

J'ai essayé d'obtenir les pouvoirs nécessaires pour commander plus de mémoire, mais je reçois une opposition massive (par exemple, rendre le logiciel plus performant, coûte trop cher pour tous ces serveurs, ou prouver que la boîte n'a pas assez de mémoire, etc. ..).

Existe-t-il des directives (ou une formule) pour la quantité de RAM dont une boîte a besoin que je puisse présenter aux non-techniciens, afin que nous puissions enfin commander plus de mémoire?

Pas vraiment un moyen de le dire facilement car cela dépend entièrement de votre utilisation et de l'application. Vous maximisez un serveur de base de données ... quelle est la taille de la base de données? Quelles sont vos statistiques de transaction?

Les limites du monde réel sont évidentes dans votre scénario. Vous exécutez pendant un certain temps sur 6 gig sans problème, puis c'est l'échange et la raclée. Donc 6 gig ne suffit pas.

Si les performances sont suffisantes pour avoir un impact sur les affaires, alors vos supérieurs devraient entendre suffisamment de plaintes pour qu'il soit prudent d'augmenter la mémoire. Calculez le coût de votre temps, puis déterminez combien il en coûtera pour "régler" le serveur et dépanner le réglage, lorsque la mémoire ajoutée au serveur peut très bien résoudre le problème du coût de la mémoire et moins d'une demi-heure de temps d'arrêt.

Vous ne connaîtrez pas la quantité exacte de mémoire dont vous avez besoin jusqu'à ce que vous déployiez réellement dans votre utilisation réelle et que vous travailliez à partir de là.

Cela dit, vous voudrez peut-être vérifier que votre application est vraiment le goulot d'étranglement. Exécutez le moniteur de performances Windows pour voir les statistiques d'E / S de votre disque et le débit réseau. Voyez également quel est votre niveau de fragmentation ( Google est un bon ami ici ). Vous pouvez également essayer d'auditer le code pour des problèmes évidents où une requête est massivement inefficace ( Google encore ).

Mais encore une fois, tout dépend de la façon dont cela a un impact sur l'entreprise. Est-ce que cela vaut la peine d'investir dans le réglage, ou est-ce déjà assez grave pour y jeter du matériel puis essayer de le régler?

Un moyen simple de voir si vous avez besoin de plus de RAM est de représenter le compteur de performances Page Life Expectancy. Ce compteur vous indique combien de temps SQL Server pense que les données seront conservées dans le pool de mémoire tampon avant d'avoir besoin de faire de la place pour d'autres données. Vous voulez que ce nombre soit le plus élevé possible. Avec 6 Go de RAM installés (vous devriez avoir SQL réglé au maximum à probablement 4 Go), vous ne conserverez probablement les données en mémoire que pendant quelques minutes au plus, lorsque quelqu'un exécutera un rapport volumineux, vous verrez ce numéro de réservoir jusqu'à quelques secondes. Plus vous avez de RAM, plus les données peuvent être conservées en mémoire et moins la lecture des disques devra être effectuée.

Par exemple, les systèmes avec lesquels je travaille en ce moment ont 256 Go de RAM et nous gardons les données en mémoire pendant environ 12000 secondes.

Veuillez ne pas demander un nombre cible à atteindre, vous voulez juste que le nombre soit aussi élevé que possible. Sans en savoir BEAUCOUP plus sur vos systèmes, je ne peux pas vous donner un bon chiffre.

Hmmmm. Eh bien, 6 concerts est une quantité décente de RAM, même pour une grande installation MSSQL. Vous voudrez peut-être regarder et vous assurer que votre code est vraiment efficace. Une transaction de 6 gig est un peu inhabituelle ... J'ai travaillé sur des systèmes de paie à l'échelle de l'État qui n'ont pas dépassé un concert à la fin de l'année 1099 ... Et en avoir un qui tourne souvent ? Je ne sais pas. Avec quel type de données travaillez-vous?

Cela étant dit, vous pouvez remplir autant de RAM que vous le souhaitez dans une boîte 64 bits, et le ram est très bon marché, alors autant y mettre autant que vous le pouvez ... Vous ne pouvez pas vraiment avoir trop de RAM sur un serveur de base de données.

Edit: Ceci est largement obsolète maintenant. J'ai des boîtes MSSQL avec 256 Go de RAM.

Avant de vous lancer dans l'achat de plus de mémoire (ou de tout autre composant), je recommanderais d'exécuter une analyse des performances sur le serveur. Vous pouvez le faire vous-même en utilisant perfmon ou vous pouvez utiliser des outils tiers. Vous devez analyser les performances du système d'exploitation et du serveur SQL. À mon humble avis, nous sommes trop souvent prêts à jeter un problème matériel avant qu'une analyse appropriée n'ait été effectuée. Pour tout ce que vous savez à ce stade, cela pourrait être un problème avec une requête, une procédure stockée, un plan d'exécution, des E / S de disque, l'utilisation du processeur, etc., etc. La pression de la mémoire peut souvent être le symptôme d'un autre goulot d'étranglement dans le système.

comme "Satanicpuppy" l'a dit, il n'y a pas trop de RAM, mais 6 Go devraient être corrects, peut-être devriez-vous repenser ce que fait votre serveur, je ne pense pas que vous ayez un problème "matériel", vous devriez concentrez-vous sur votre programmation SQL ...

En ce qui concerne les serveurs de base de données, il n'y a pas de mémoire "suffisante". Bien sûr, cela dépend de ce qu'ils font et exécutent réellement, mais s'il s'agit d'une base de données constamment utilisée contenant beaucoup de données et effectuant des requêtes compliquées - 6 Go pourraient facilement être largement insuffisants.

Je commencerais par mettre à niveau un serveur gênant vers au moins 32 ou 64 Go et voir si cela aide. Sinon, passez à l'optimisation de la base de données, au dépannage et au débogage des applications - qui, à moins qu'un idiot n'ait conçu la base de données, coûtent beaucoup plus que quelques bâtons de mémoire de qualité serveur (et même si un idiot a conçu la chose, obtenant une conception encore plus évidente) les erreurs corrigées avec le support conservé pourraient s'avérer assez difficiles).

Cela dit, comme quelqu'un d'autre l'a déclaré - cela pourrait être quelque chose d'autre le retenant (à part des problèmes de conception de logiciels), comme un manque de performances d'E / S sur le disque ou le réseau - embaucher un DBA pro pour simplement passer par la surveillance de base des performances SQL pour un journée pourrait se révéler utile.

Vous devriez envisager de créer plus d'index. Je pense qu'en général, la plupart des gens sous-indexent leur base de données.

C'est toujours du code aérien, je n'ai pas encore entièrement testé, mais cela devrait vous mettre dans la bonne direction

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