DSC: nictdl5.exe has consumes lots of CPU cycles when idle

[JKSH]

Hello,

I have LabVIEW + DSC 2012 SP1 installed on my PC (CPU: Intel Pentium D 925, OS: Windows 7 Ultimate SP1 x86). When I boot up my PC, without doing anything, the CPU usage by nicitdl5.exe consistently oscillates between 45% and 10%:

Why would this be? I have no shared variables deployed on my PC, and I have no databases in the Citadel 5 Universe:

These actions had no effect on CPU usage...

• Stop the NI Variable Engine service
• Stop the NI Citadel 4 Service
• Unplug my PC from the network

...while this brought CPU usage to near-0:

• Stop the NI Citadel 5 Service

I will be needing Citadel for some work. How do I bring down its CPU usage?

Thanks!

[JefeL]

After some research, we were only able to find slightly relevant information on this problem. There is a KnowledgeBase that mentions an empty alarm trace in the Citadel 5 data base but that would cause sqlservr.exe to use the CPU. You might take a look at it here and see if you can find any relevant connection to your use case:

http://digital.ni.com/public.nsf/allkb/443031C42AA02E0E862570B60065C867?OpenDocument

Additionally, could you attach a MAX technical support report? Perhaps there is something in there that would give us more of an idea as to what might be happening behind the scenes.

[JKSH]

Thanks Jeff.

I had a look at your link, but couldn't find anything that seems relevant. I have no alarm traces (empty or otherwise).

The forum rejected my attachment because it is too large (7.4 MB). I've uploaded the MAX technical support report to Google Drive instead: https://drive.google.com/file/d/0B71n5SNZeRJybHBEX05sNjR2dkk/edit?usp=sharing (although I plan to delete it in a few days' time)

[JefeL]

It looks like the database may be performing normal operations such as creating indexes for system variables or repairing after a possible corruption. I understand your database appears empty but even a new database can have hidden system tables. Can you try letting it run overnight to see if the problem goes away with time. Note that stopping the process will most likely make it start over and take longer as well.

[JKSH]

Thanks for the suggestion. I'll try it and let you know the outcome.

[JKSH]

My PC has been on for the past 18 hours, while being in active use for the first 3 of those hours. I have not done any DSC-related activities or deployed any shared variables in my PC ever since my first post in this thread.

However, nictdl5.exe is still actively using 26% of my CPU on average.

I'll continue to use my PC now, and see how it is at the end of the day.

[JKSH]

It has now been 26 hours; still no improvement. I'll let it run over the weekend and see what happens.

[JKSH]

No improvement after letting the PC run for >3 days. Any ideas what could be causing this?

Is there a way to fully clean out old Citadel caches and start with a clean slate?

[JefeL]

What happens when you create a dummy database?

Can you find a file called sdb_lock in the directory where your databases are stored?

[JKSH]

Ok, extremely weird, but things are better now 🙂

1. I created a new dummy database. No change in CPU usage (still averaging at 26%)
2. I deployed a dummy variable, with logging enabled. No change in CPU usage.
3. I wrote a value into the dummy variable. CPU usage dropped to 0.
4. I deleted my dummy variable (process) and database. CPU usage is still 0.

There is an sdb_lock C:\Program Files\National Instruments\LabVIEW 2012\data whenever my dummy variable process is running, but it disappears when the process is stopped. sdb_lock is perpetually found in C:\ProgramData\National Instruments\Tagger\database (I presume that the Default Database is always reserved by Citadel?). My new dummy database in C:\DummyDB never got any locks.

I did not get to check the database folders before the issue was resolved.

IIRC, I noticed the high CPU usage when Citadel was active. That's why I stopped and deleted all my variable processes, and deleted my databases. (This is a development PC so I only had dummy test data). However, that didn't reduce CPU usage. Who would've thought that the final solution was to write into the database?