Sqlservr.exe CPU usage very high

[MarkB 89]

I upgraded to Lookout 6.0.1 from 5.1.

Now there is a very high cpu usage with the sqlservr.exex process and causing a major slow downof the computer. Makes it very difficult to program lookout. I notice in other threads there are various problem with high cpu usage. When i first converted the database this high usage was there but i let the computer run without lookout running and after about 24-30 hours this usage stopped and lookout ran normal. Now the high usage is back after the computer was mistaklingly started as the network administrator when normally it is just the local administrator. Even after logging on as the local admin it still has the high usage.

If there is a patch for this please let me know or the only other thing is to go back to Lookout 5 but how do i convert the database back

Thanks

[Ame_G]

Mark8,

Lookout 6.0.2 was released last week and there are fixes for the problems you have in lookout 6.0.1. You can download the update from the link below http://digital.ni.com/softlib.nsf/websearch/E9A7448EF92727E786256F9A006E26BD?opendocument&node=132060_US. You have to uninstall and version of Lookout 6.0.x before installing 6.0.2.

Ame G.
Application Engineer
National Instruments

[MarkB 89]

I did install the new version but the sqlservr process is still using alot of the cpu. As I understand it the sqlservr is used for the alarms and events. My database goes back to 2001. Is it possible that there is a conversion process going on fron Citidel 4 to 5 that is using all of this processor time. And if so is there a way to delete the alarms and event part of the database as I really don't need this historical info just my traces points

Thank you

[Ame_G]

MarkB,
Here is some more information that will help you solve the high CPU usage of he sqlsrvr.exe. This high CPU usage occurs when there is an empty "phantom" alarm trace in the Citadel database.

The problem can be resolved by archiving the database. Please follow the steps below to archive your database.
1) Shutdown Lookout and wait several minutes to ensure any active alarms are stored permanently to the database. Failure to do so will cause any alarms generated after the archive process starts to be lost.
2) Open MAX.
3) Browse to the database that is causing the issue in Historical Data under My Computer.
4) Right-click on the database and choose "Archive"
5) When prompted to select a destination database, create a new database in known location.
6) Let the archive process complete.
7) You now have the option of reconfiguring the process to log to the new database, or you can detach the original database, move it to a backup location, then reattach the newly created archive with the same name as the original database.

Please check the link below on how to delete traces from your database.
http://ae.natinst.com/operations/ae/public.nsf/web/searchinternal/762d1a1efec7554c86256c6800756bc5?OpenDocument

Regards,
Ame G.
National Instruments

[MarkB 89]

Thank you Ame

I recently did just as you said by archiving the database and the high usage did stop. I was wondering is there a way to find that phantom trace or is it not worth the trouble being the databases are operating fine right now. I have all the data traces and really dont mind losing any of the alarm history.

Thank for your help

[Turd]

My sql was 75% and csmain was 25%, i performed the archive procedure and now my csmain is 80% and sql 20% cpu.  Whats next?

[Ryan.S]

The high cpu of sql is the Citadel issue. It will probably be fixed by archiving the database. But the csmain is DL driver management utlity, it seems a different issue from the sql usage.

Try to detach(not delete) the current database and create a new one. Let Lookout log data to the new empty database and see if the cpu usage will drop down.

 Do you use Lookout or LookoutDirect? which version?

[Turd]

I'm using lookout 6.1 build 27.

[Ryan.S]

You are using the DL driver object from Automation Direct, right? I don't know much about the high cpu usage of csmain.exe. You'd better contact Automation Direct.

If you stop NI CItadel 5 service, and the SQL server service, will the cpu of csmain.exe go down? Although I don't think the sql server could affect the csmain.exe, we need to verify it first.

[Turd]

Got it....Poll rate of the DL drivers.  I have always left them blank, now I've set them all to 500ms.  Csmain has gone from 90% to 20%.  We have doubled the processors over the past year, I think it has begun to overload things.  Hmmm, might explain the router issue too...OK now u guys got me babbling..