August 7, 2012 at 1:52 pm
I've seen a lot on LSASS.EXE CPU and Memory Bloating. Since I'm having the problem in the context of SQL Server, I'm posting in this forum....but the hotfix solution i found might be the answer to other lsass.exe issues.
Note: I don't post a lot so please forgive me if I break some rule of etiquette
My issue:
LSASS.EXE process consumes a lot of CPU...in my case maxed out to 100%.
I am on a WIN 2008R2 SP1 Server and doing a SQL Server 2008R2 Backup maintenance plan that includes file maintenance on TRN and BAK files (deleting old files by date).
Lots of DBs (A sharepoint system)....maybe 50 or so. Keeping a week of daily BAK and every-15-min TRN files....so the number of trn&bak files is a lot...but the total amount of data is not huge.
Also of note, the Full backup maintenance plan job takes 35 minutes but should only take 5 minutes given the data. I am using compression so i suspect the CPU issue is slowing down the backups.
BUT
I discover the CPU bloat for LSASS.EXE is happening during the file maintenance steps ...not the backup step. Evidently there is a lot of Active Directory authentication happening... maybe directly related to the number of files....so LSASS.EXE is executing a lot. I forgot to mention that LSASS.EXE is a microsoft Active Directory authentication resoution process. Still there shouldn't be 100% CPU usage.
I then discovered the answer in a hard to find Hotfix (these seem always hard to find even when you search using the right terms).
http://support.microsoft.com/kb/2545833
seems the CRYPTDLL.DLL used by LSASS.EXE is written poorly and is slow and eats CPU....maybe even a memory leak. Anyway, the hotfix addresses it and is for Windows Server 2008R2 with or without SP1. You can tell if you need it by looking at the version of your server's CRYPTDLL.DLL (right click/properties). The link gives the version numbers.
Hope it helps someone. if you find other LSASS.EXE related solutions post them here if you want...might help someone like me.
August 7, 2012 at 2:10 pm
Note: I don't post a lot so please forgive me if I break some rule of etiquette
You just posted to tell everyone "Here's a problem I had, here's what I did to fix it just in case anyone else comes across this"?
You haven't broken any forum etiquette... You just made the awesome list!
August 7, 2012 at 4:36 pm
Heimillers (8/7/2012)
I've seen a lot on LSASS.EXE CPU and Memory Bloating. Since I'm having the problem in the context of SQL Server, I'm posting in this forum....but the hotfix solution i found might be the answer to other lsass.exe issues.Note: I don't post a lot so please forgive me if I break some rule of etiquette
My issue:
LSASS.EXE process consumes a lot of CPU...in my case maxed out to 100%.
I am on a WIN 2008R2 SP1 Server and doing a SQL Server 2008R2 Backup maintenance plan that includes file maintenance on TRN and BAK files (deleting old files by date).
Lots of DBs (A sharepoint system)....maybe 50 or so. Keeping a week of daily BAK and every-15-min TRN files....so the number of trn&bak files is a lot...but the total amount of data is not huge.
Also of note, the Full backup maintenance plan job takes 35 minutes but should only take 5 minutes given the data. I am using compression so i suspect the CPU issue is slowing down the backups.
BUT
I discover the CPU bloat for LSASS.EXE is happening during the file maintenance steps ...not the backup step. Evidently there is a lot of Active Directory authentication happening... maybe directly related to the number of files....so LSASS.EXE is executing a lot. I forgot to mention that LSASS.EXE is a microsoft Active Directory authentication resoution process. Still there shouldn't be 100% CPU usage.
I then discovered the answer in a hard to find Hotfix (these seem always hard to find even when you search using the right terms).
http://support.microsoft.com/kb/2545833
seems the CRYPTDLL.DLL used by LSASS.EXE is written poorly and is slow and eats CPU....maybe even a memory leak. Anyway, the hotfix addresses it and is for Windows Server 2008R2 with or without SP1. You can tell if you need it by looking at the version of your server's CRYPTDLL.DLL (right click/properties). The link gives the version numbers.
Hope it helps someone. if you find other LSASS.EXE related solutions post them here if you want...might help someone like me.
Let's make it easier for others:
August 10, 2012 at 3:24 am
@Heimillers
you saved my day with your post. I found your link via this tweet:
from my experience since last year with sbs2011, the whole system is quite crappy
there was nothing as stable as the 2003 version.
this version has a lot of more functionalities, but seems to be more an untameable beast.
for 'no reason' suddenly since 3 days lsass was eating 100% of CPU when doing file processing.
Just installed the fix, wondering what result it will give after reboot 2night.
my best
Kristof Bernaert (@ssstofff)
August 13, 2012 at 11:33 am
installed the fix, rebooted, same bloat...
I'm experiencing the same behavior as detailed above, I have not pinpointed it to the backups/maintenance plans but something is soaking the lsass process to the point of killing the machine.
August 14, 2012 at 10:39 am
Yeah, there's a lot out there on lsass.exe ... none of it applied to me until i found this one.
if its a domain controller, there is another fix.
http://support.microsoft.com/kb/2550044
if Windows 2003 then this link: http://support.microsoft.com/kb/939268
There's also this issue with IIS where a certain setting can be changed to only check active directory once per session rather then every transaction. Dont have a link.
Keep searching on "lsass.exe cpu" ... lots out there....its some process related to many or inefficient active directory calls.
Also, For this fix, Verify you are using Win Server 2008R2 and make sure you check the version of Cryptdll.dll to make sure its updated to one of the versions mentioned in the article.
P.S. Those of you who found the original helpful, thanks for the encouragement.
August 14, 2012 at 12:42 pm
if its a domain controller, there is another fix.
the domain controllers are one of the next places I'm looking at.
I've also read up on bumping the MaxConcurrentAPI up to 150 (Server 2008 R2).
There's also this issue with IIS where a certain setting can be changed to only check active directory once per session rather then every transaction. Dont have a link.
Are you referring to Kerberos authentication..? If so, this is another point of focus.
Also, For this fix, Verify you are using Win Server 2008R2 and make sure you check the version of Cryptdll.dll to make sure its updated to one of the versions mentioned in the article.
double-checked this after completing the update and reboot. It takes about 24hrs for our lsass to consume all of the memory, I do have the memory capped in SQL server to 80% of the total RAM. The creep doesn't seem to align with any job or process, just slowly climbs (1%, 2% at a time) until maxed out.
P.S. Those of you who found the original helpful, thanks for the encouragement.
thank you for getting the discussion going specific to sharepoint and it's databases
January 3, 2019 at 2:50 pm
I came across this post a little too late. In fact the symptoms my servers are showing are exactly as described on the original post but I'm running on Windows Server 2012 R2.
Has anybody heard of a similar problem on 2012? is there any patch for this OS? (the original link points to a hotfix that is specific to 2008 R2)
Thanks!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply