December 15, 2009 at 12:15 pm
Hi there,
I'm currently in the process of trying to debug a performance issue on a dev server that we have. Basically this machine contains developer databases, which are not that big, along with a bunch of SSIS packages that are triggered via SQL jobs. These packages run fairly often so there's always some DTExec process running but this is not really my concern.
The server constantly shows lsass peaking between 30%/50% of CPU usage in the task manager.
I'll describe the setup of the applications using the server as this may help understanding the situation. Basically each developer runs his own application server locally that connects to this server. The application relies on SQL authentication and does make use of XA transactions using Microsoft's JDBC driver (ie each login has to have a user in master and be part of the DBRole SqlJDBCXAUser that is used to make calls to a DLL shipped with the JDBC driver that allows two-phase commits.
One of the things we've done in the past to try and minimize the AD callbacks is to disable the Password Policy Check on the logins, which has considerably reduced the amount of security audits in the eventviewer that used to look like this:
Password Policy Checking API is called:
Caller Username:SQLSERVER$
Caller Domain:DOMAIN
Caller Logon ID:(0x0,0x3E7)
Caller Workstation:127.0.0.1
Provided User Name (unauthenticated):-
Status Code:0x0
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.%5B/quote%5D
So this I though would help reduce the load on lsass, but it appears that not much has changed. The SSIS packages use connections that use SQL authentication as well, all done via environment variables that point to dtsconfig files.
I'm just wondering if there are any things I could try to see if lsass could calm down and stop hogging CPU time like that? I'm not too sure what is going on and I can't put the server on and off too much during daytime so I'm going to wait until tonight to investigate things a little further. In the meantime, if anybody has any idea, please don't hesitate to post them 🙂
Regards,
Greg
December 15, 2009 at 12:58 pm
I just disabled all my jobs and my lsass process has gone down dramatically.. This is weird, it looks like some issue with DTEXEC when running the packages as a job more than via BIDS. I'm gonna look more into it and post any results I find here. In the meantime, if anybody has more info, let me know 🙂
Greg
December 15, 2009 at 3:09 pm
Alright so more info ... When a dev runs the package from his workstation, it's his workstation's lsass that goes up, not the server's, which makes sense. same thing if i run the package from the BIDS on the actual server, it goes up, just like the job. So this is probably not a job-related issue here, but i'm still very intrigued as to what lsass has to do with a package's execution.
Any ideas are welcome.
Regards,
Greg
December 15, 2009 at 3:47 pm
Alright after more digging it's only happening when my packages are called via the execute package task in the control flow. I can't understand why this would make a difference but there it is...
December 16, 2009 at 9:52 am
My last piece of info before trying to drop a call at Microsoft...
I was able to narrow down the issue to derived columns and lookups in my data flow transformations. Without them the lsass process stays at 0%. Weird thing is that this issue is still only happening when the package is called via another package...
I really am puzzled by this issue.
Greg
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply