L'utilisation de la mémoire non paginée par le processus EVEN (enregistreur/visualisateur d'événements) augmente jusqu'à épuisement.

La première chose à vérifier est de s'assurer que max server memory (MB) est défini dans le serveur SQL. Il s'agit d'une option de serveur qui indique à SQL Server "voici toute la mémoire dont vous pouvez disposer". Par défaut, SQL Server utilisera toute la mémoire disponible pour des choses telles que les caches de données, ce qui peut être une mauvaise nouvelle dans un environnement partagé tel que le vôtre.

Dans votre instance SQL, ouvrez une nouvelle fenêtre de requête et tapez :

sp_configure 'show advanced options',1
GO
RECONFIGURE
GO
sp_configure 'max server memory (MB)'

Si la valeur de config_value est 0, cela signifie que le serveur SQL est autorisé à utiliser toute la mémoire qu'il souhaite. Dans ce cas, vous devriez le régler sur quelque chose de plus raisonnable pour votre environnement.

Vous ne mentionnez pas la quantité de mémoire dont dispose votre serveur, mais comme vous êtes dans un environnement 32 bits (et que vous ne précisez pas non plus quelle édition de Windows), je vais partir du principe que vous disposez de 4 Go. Vous voudrez peut-être limiter SQL à 1 Go pour permettre l'utilisation d'autres services d'application. Vous pouvez procéder comme suit :

sp_configure 'max server memory (MB)',1000
GO
RECONFIGURE
GO

Si vous utilisez Windows 2003 Enterprise et que vous disposez de plus de 4 Go de mémoire, vous pouvez bien entendu définir la mémoire maximale à un niveau supérieur.

Vous pouvez également envisager d'utiliser les extensions de fenêtrage d'adresses (AWE), qui peuvent vous donner un peu plus de marge de manœuvre. Vous trouverez des informations à ce sujet sur TechNet aquí .

Lorsque le problème se produit, ouvrez le Gestionnaire des tâches et ajoutez la commande Handles colonne. Effectuez un tri sur cette colonne et recherchez les valeurs qui semblent excessives. Il peut être utile d'obtenir une base de référence du serveur au démarrage et au fil du temps. Combien de temps s'écoule-t-il après le démarrage avant que le problème ne se manifeste ? Il y a de fortes chances que le processus ayant le nombre de handles le plus élevé ou le plus inhabituel soit le coupable, bien qu'il soit difficile de déterminer exactement pourquoi.

Dans mon cas, j'ai constaté que cela était dû à une désinstallation ratée de l'agent CommVault (sauvegarde) qui a laissé derrière elle un service non fonctionnel qui créait deux handles dans HKCU (registre) toutes les quelques secondes. Chaque handle ouvert consomme de la mémoire et a fini par mettre à genoux l'environnement Exchange d'une organisation entière.

Sysinternals handle.exe peut également être utile pour voir quels processus utilisent de nombreuses poignées et à quels objets ils sont attachés.