J'essaie de trouver une manière saine de comprendre si le max server memory (mb)paramètre est approprié (soit être plus bas, soit plus haut, ou rester tel quel). Je suis conscient que cela max server memory (mb)devrait toujours être suffisamment bas pour laisser de la place au système d'exploitation lui-même, etc.
L'environnement que je regarde compte plusieurs centaines de serveurs; J'ai besoin d'une formule fiable que je peux utiliser pour déterminer si la taille actuelle du pool de tampons est appropriée, car la RAM est calculée par Go alloué à chaque serveur. L'environnement entier est virtualisé et la RAM «physique» allouée à une machine virtuelle peut facilement être modifiée à la hausse ou à la baisse.
J'ai une instance SQL Server particulière que je regarde maintenant avec un PLE de 1 100 052 secondes, ce qui équivaut à 12,7 jours (la durée de fonctionnement du serveur). Le serveur a un paramètre de mémoire maximale du serveur de 2560 Mo (2,5 Go), dont seulement 1380 Mo (1,3 Go) sont réellement engagés.
J'ai lu plusieurs articles dont un de Jonathan Keheyias ( post ) et un autre de Paul Randal ( post ), et plusieurs autres. Jonathan préconise la surveillance d'un PLE inférieur à 300 par 4 Go de pool de mémoire tampon comme étant trop faible. Pour l'instance SQL Server ci-dessus, il en 300 * (2.5 / 4) = 187résulte un PLE cible vraiment très bas en dessous de 300. Cette instance a 290 Go de données SQL Server (sans les fichiers journaux) et n'est utilisée que pour les tests d'intégration. En supposant que les 12 derniers jours sont représentatifs de l'utilisation typique de ce serveur, je dirais que le max server memory (mb)paramètre pourrait être réduit.
À l'autre extrémité de l'échelle, j'ai un autre serveur de test d'intégration avec un PLE de 294, qui a un max server memory (mb)paramètre de seulement 1 Go. Ce serveur ne dispose que de 224 Mo de données SQL Server, journaux non compris, et exécute certaines bases de données BizFlow. Ce serveur peut bénéficier d'un max server memory (mb)paramètre plus élevé .
Je pense qu'un bon point de départ pour les cibles auxquelles on pourrait attribuer trop de mémoire pourrait être de regarder:
SELECT
RamMB = physical_memory_in_bytes / 1048576
, BufferPoolCommittedMB = bpool_committed * 8192E0 / 1048576
, BufferPoolCommitTargetMB = bpool_commit_target * 8192E0 / 1048576
, PercentOfDesiredSizeMB = CONVERT(INT,(CONVERT(DECIMAL(18,2),bpool_committed)
/ bpool_commit_target) * 100)
FROM sys.dm_os_sys_info;
Si BufferPoolCommitTargetMB / BufferPoolCommittedMBest supérieur à 1, le serveur n'utilise pas la totalité du pool de tampons. Si la machine en question a également un PLE supérieur à "x", elle pourrait être un bon candidat pour une diminution de max server memory (mb).
Étant donné que le Buffer Manager:Lazy writes/seccompteur de performances suit le nombre de fois que SQLOS a écrit des pages sur le disque entre les points de contrôle en raison de la pression de la mémoire, cela peut être une autre bonne chose à regarder.
DECLARE @WaitTime DATETIME;
SET @WaitTime = '00:00:15';
DECLARE @NumSeconds INT;
SET @NumSeconds = DATEDIFF(SECOND, 0, @WaitTime);
DECLARE @LazyWrites1 BIGINT;
DECLARE @LazyWrites2 BIGINT;
SELECT @LazyWrites1 = cntr_value
FROM sys.dm_os_performance_counters dopc
WHERE (
dopc.counter_name LIKE 'Lazy writes/sec%' COLLATE SQL_Latin1_General_CP1_CI_AS
)
AND dopc.object_name = 'MSSQL$' + CONVERT(VARCHAR(255),
SERVERPROPERTY('InstanceName')) + ':Buffer Manager';
WAITFOR DELAY @WaitTime;
SELECT @LazyWrites2 = cntr_value
FROM sys.dm_os_performance_counters dopc
WHERE (
dopc.counter_name LIKE 'Lazy writes/sec%' COLLATE SQL_Latin1_General_CP1_CI_AS
)
AND dopc.object_name = 'MSSQL$' + CONVERT(VARCHAR(255),
SERVERPROPERTY('InstanceName')) + ':Buffer Manager';
SELECT LazyWritesPerSecond = (@LazyWrites2 - @LazyWrites1) / @NumSeconds;
Le code ci-dessus suppose que le serveur est sous charge pendant les 15 secondes nécessaires à son exécution, sinon il affichera 0; qui pourrait être un faux négatif trompeur.
Dois-je également consulter les PAGELATCHIO_*statistiques d'attente ou un autre type d'attente comme indicateur de la pression sur la mémoire ou de son absence?
Ma question est, comment puis-je déterminer de manière fiable une "bonne" valeur cible pour PLE et max server memory (mb)?
la source
max server memory (mb), et en tant que tel, je suis assez réticent à les réduire. Cependant, certaines autres instances ont 1000000 + PLE, et en tant que telles sont des candidats potentiels assez évidents pour une baisse de RAM. De toute évidence, l' abaissement RAM entraînera une augmentation IOps, et je ne suis pas sûr de ce que le coût de ce sera.max server memorycadre est une sorte de chose avec du poulet et des œufs; plus lemax server memoryréglage est bas , plus le PLE minimum "acceptable" serait bas, donc je pourrais rester coincé dans une spirale toujours plus basse. Je suis sûr, comme vous le mentionnez, que les performances des utilisateurs seront à un moment donné affectées.Le T-SQL actuel que j'utilise pour évaluer PLE vs
max server memoryest:Ce code compare le PLE à un PLE "acceptable" minimum pour la quantité de
max server memorysystème configurée. Si le PLE est sensiblement supérieur au nombre acceptable, il suggère un maximum de 10% inférieurmax server memory. Si le PLE est inférieur au PLE acceptable, il suggère un maximum de 10% de plusmax server memory.Si la quantité réelle de pool de mémoire tampon validée est inférieure à la taille de pool de mémoire tampon cible, elle suggère de réduire
max server memorycette quantité, ainsi que de la mémoire supplémentaire pour les threads, les écritures différées, etc.Le code examine également divers compteurs de performances pour des choses comme les écritures paresseuses / seconde, les décrochages de liste gratuits et les demandes de lots.
Le code n'est pas parfait, je le partage ici pour obtenir des commentaires et pour le bénéfice des futurs utilisateurs de SO.
la source