I could use some insight on this one...
Current setup: Server 2003, SQL 2005, NPM 9.5 SP3, APM 2.5
Here is what is going on: about 2 weeks ago the NPM website was VERY slow to respond. I have written some little custom resources that perform a simple LDAP query and just populate a small gridView. Any page that had this resource on it was taking even longer. To double check this, I ran the same query directly on the DC- it responded immediatly. After troubleshooting for quite a while, I found nothing...even after removing the custom resource. At this time the website became completely unresponsive...I hopped on the server to see that the LSASS host process had eaten up something like 1.4 GB of physical memory- and it was still eating more and more...when it got up to 2.0 GB, I headed to the datacenter. By the time I got there, it had released all the memory for that process, and the services were responsive again.
I had opened Case #111984 about this a while back. Thinking that it may have been similar to the w3wp hogging resources, I was given SP3 dll's to try to fix, but it did not help- as the lsass.exe process continued to slowly eat memory and not release it...or not enough to keep up:
I went back to the case, and David from Support did a GoTo meeting to check a few things on the server- he was very helpful, but we were still unable to find anything concrete as to why lsass was so hungry...the only thing that allowed the process to get back to a more reasonable amount of allocated memory was to turn off a script monitor that simply goes out to remote machinesand checks to see if there are specific files older than 60 minutes old.
A few notes:
-The component runs with domain admin credentials
-These credentials are NOT the same as the service account that all the NPM/APM/SQL services run as....and changing the them to run as the service account does not help.
-When the component is enabled, there are a TON of lsass threads, and a TON of tokens under the same user as the component is running
While I don't believe it is related specifically to my script, I will post it at the end for the script gurus out there. Even with this script, the lsass process still consumes a LOT of memory....we've got a few other components, added to APM, but not too many. Are they all authenticating in such a way that the lsass process is not letting memory go? Any help/thoughts on this one are appreciated. Thanks guys:
Here's the script- the args are the IP address of the machine...the loops are to navigate down to subdirectories etc. Wondering if using IP address in UNC path which causes LM\NTLM authentication is related to this issue????
'############################################
'# IMTEMPScript.vbs A Script for counting #
'# files in IMTEMP for the APM daemon #
'# Returns Statistic: with number of images #
'# Older than varTime minutes old #
'############################################
Option Explicit
On Error Resume Next
Dim args, path, objFSO, objRootDir, objFiles, objFolders, folder, objBatch, scan, varTime, oldImages
varTime = 90
oldImages = 0
Set args = WScript.Arguments
If args.Count = 1 Then
path = "\\" & Trim(args(0)) & "\IMTEMP\"
Else
WScript.Echo "Usage: Args must be IP address for UNC path to scanning machine"
WScript.Quit(1)
End If
Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
If objFSO.FolderExists(path) Then
Set objRootDir = objFSO.GetFolder(path)
If (IsEmpty(objRootDir) = True) Then
WScript.Echo "Statistic: 0"
WScript.Quit(1)
Else
Set objFolders = objRootDir.SubFolders
For Each folder In objFolders
Set objBatch = objFSO.GetFolder(path & folder.Name)
If Not (IsEmpty(objBatch) = True) Then
Set objFiles = objBatch.Files
For Each scan In objFiles
If InStr(LCase(scan.Name), ".tif") <> 0 Then
If DateDiff("n", scan.DateCreated, Now()) > varTime Then
oldImages = oldImages + 1
End If
End If
Next
End If
Next
End If
End If
WScript.Echo "Statistic: " & oldImages
Set objFSO = Nothing
WScript.Quit(0)
