Excessive memory usage of DSC engine/sqlservr.exe

[dietrich]

Hi,

I have an application using LabVIEW DSC. About 2000 tags are configured in the scf file. In principle things are running fine. However, after one week of uptime the usage of virtual memory starts to increase dramatically.

Example (after one week of operation)
DSCEngine.exe, memory: 150MB, virtual mem: 400MB
sqlsrvr.exe, memory: 200MB, virtual mem: 300MB

After about two weeks, Windows displays a message: "Your system is low on virtual memory. Windows is increasing the size of your virtual memory paging file. During this process, memory requests for some applications may be denied. For more information, see Help".

Then, my application crashes.

The PC is a dual PIII with 1GB of RAM.
OS is XP, SP1
LabVIEW and DSC are version 7.1
Read/write operations to LabVIEW DSC are performed 5 to 10 times per second.

Any ideas?

Cheers,

Dietrich

[A.S.]

Hi Dietrich,
Have you applied the latest DSC fix?
http://digital.ni.com/softlib.nsf/websearch/6A771B1EBA7E670786256F49006F3693?opendocument&node=132070_US

For the alarm configuration of your tags, do you have auto-acknowledge enabled? If so, try disabling that and see what kind of results you get. Do you see the same behavior on a single-processor machine? Please check the following document on tips on high-channel count DSC systems:
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/e6a1f57863e8d7e686256a140050a90b?OpenDocument#4

Hope this helps.

[dietrich]

Hi A.S.,

o.k., I have read the document but found nothing new. I never use the auto-acknowledge feature. Regarding the patch: I had not applied it yet, but I have done this just today. We had similur problems already on single processor machines, but right now it would be a bit hard to reproduce. O.k., let's wait one or two days and see, whether the new patch helps.

Another thing that I find a bit strange: The folder containing the DSC data (as for historic trending) contains a file named "mssql.mdf", which has an impressive size of more than one GByte. All other files have a size of about 1MByte.

Cheers,

Dietrich

[dietrich]

Hello,

o.k., I have applied the patch recommended by A Saha. The problem with the virtual memory size of the DSCEngine.exe seems to be solved. Not solved is the memory consumption of the sqlservr.exe. There must be a correlation between the DSCEngine and the sqlservr.exe, since the virtual memory size of sqlservr.exe only increases, if the DSCEngine is running.

Cheers,

Dietrich

[nickf]

LabVIEW DSC 7.x uses the Citadel5 database to store trace data and MSDE 2000 (Microsoft SQL Server 2000) to store alarm and event data.

You mentioned that the msslql.mdf file was growing to over 1Gb in a one to two week time frame. The most likely reason that this is happening is that you have many alarms and events configured. I recommend checking any alarm or event related deadband settings to make sure you aren't logging alarms and events unnecessarily. Also note that MDSE databases are limited to 2Gb. Citadel performance will degrade significantly if you try to log alarms and events past this limit.

The memory usage issue for MSSQL is also related to the size of the alarms and events database. MSSQL runs an indexing service in the background that takes up a lot of memory and CPU time. This issue should also be resolved if you reduce the amount of alarms and events that are being logged.

If the alarm and event logging that you currently have configured is absolutely necessary I recommend logging to a new databse each week or so. This could be accomplished manually through the tag configuration editor, or programatically via LabVIEW. Each time you start a new database I recommend detaching (but not deleting) the previous database.

Nick F
National Instruments

[dietrich]

Hi Nick,

I think my dead bands are fine. The trick of shutting down the DSC engine and to switch to a new database certainly helps. However, there might be another point. There seems to be a difference between the DSC engine in the "Development System" and the DSC engine in the "Runtime System". The "Runtime System" is significantly less memory hungry. We have a couple of control systems operational and some of my users report the same experience.

O.k., the problem seems to be under control. However, I am hoping that you, the NI people in Austin, keep an open eye on that point for LabVIEW 8.

cheers and thanks for your help,

Dietrich