Jump to content

Memory usage issue with SQL toolkit


Recommended Posts

CITATION(alukindo @ Mar 27 2007, 06:16 PM)

TiT:

I recreated your database in MS SQL Server and I was able to duplicate the memory leak. I got exactly 4 kb of memory leak for each database call from the database VI. I also determined that the fix I suggested previously did not fix the problem.

However, when I opened the connection just once and left it open in a shift register, the memory leak problem went away. I am attaching your code modified to leave the connection open until DB operations are done. I tested this on my MS SQL Server and it looks OK now.

I hope this helps

Anthony Lukindo

Thanks a lot for the time you spent doing this ! I really appriciate this. :worship:

When I started the project, I was thinking it would be better to open/write/close each time because I only write at 0.2Hz in the DB. Now I'll code a single open, a single close and a "check if ref is still ok" for when I want to write.

Someone suggested this before, I guess I should have picked the advice at once. :oops:

Link to comment

QUOTE(TiT @ Mar 27 2007, 08:54 AM)

I'm not trying to break any record... just to find out how not to suck up all the memory :book:

I should have remebered I was talking to a second generation Wire-Worker.

Back in the old days....

Music was recorded on a vinyl disk by modulating the depth of cut of a spiral groove with the information that is to be recorded. The vinyl disks were called "records".

Very often the the records would get scratched or broken resulting in the probe ( a needle) following the crack or scratch rather the the spiral groove. When this happened the same inforamation would be read reapeatedly. It was common "back in the old days" to refer to someone that was repeating the same thing over and over again as a "broken record".

Related tidbit:

When a song gets "stuck in my head" I feel that I "have a scratch in the record of my brain." The part that stores "It's a Small World" is one of those areas.

Ben

Link to comment

CITATION(Ben @ Mar 27 2007, 07:33 PM)

I should have remebered I was talking to a second generation Wire-Worker.

Back in the old days....

Music was recorded on a vinyl disk by modulating the depth of cut of a spiral groove with the information that is to be recorded. The vinyl disks were called "records".

Very often the the records would get scratched or broken resulting in the probe ( a needle) following the crack or scratch rather the the spiral groove. When this happened the same inforamation would be read reapeatedly. It was common "back in the old days" to refer to someone that was repeating the same thing over and over again as a "broken record".

:shifty: You should have told me "scratched DVD" to avoid any potential confusion !

I guess I was to focused on my issue and it slowed down my understanding routine :D

Link to comment
  • 3 weeks later...

QUOTE(TiT @ Mar 6 2007, 03:16 AM)

Haha! 256MB is enough for XP if you run nothing else on it!

Running and SQL Server and LabVIEW is definitely stretching the limit to an almost inacceptable point. Tell the customer that 512 MB memory is really not a lot for Windows XP and SQL Server alone and that LabVIEW also needs a bit of memory to work. Saving on memory nowadays with the prices being so low for hardware is simply stupid (But you better don't say that verbatim to your customer).

Rolf Kalbermatter

QUOTE(yen @ Mar 8 2007, 02:22 PM)

4 bytes = one I32 number = one reference.

It sure sounds like you're opening a reference and not closing it.

To check if this is a driver issue you can use the same driver and create a simple loop which runs many times and does the open-insert-close cycle. If there is a problem, you should see it even there. If not, can you upload the actual VI whose images you posted?

A LabVIEW refnum typically takes more than 4 bytes. The refnum itself is a 32bit value but it points internally to a structure containing the actual management data associated with that refnum such as the OS handles and other necessary data for LabVIEW to manage that refnum.

Rolf Kalbermatter

Link to comment

CITATION(rolfk @ Apr 12 2007, 10:50 AM)

Haha! 256MB is enough for XP if you run nothing else on it!

Running and SQL Server and LabVIEW is definitely stretching the limit to an almost inacceptable point. Tell the customer that 512 MB memory is really not a lot for Windows XP and SQL Server alone and that LabVIEW also needs a bit of memory to work. Saving on memory nowadays with the prices being so low for hardware is simply stupid (But you better don't say that verbatim to your customer).

Rolf Kalbermatter

Indeed Rolf ! I couldn't be more in agreement, one would have to be very tight @$ to purchase 10.000 $ control system (PC + sensors + cFP controller + cFP module) and try to save money on the RAM !

I did point that fact to the customer, he answered that he was going to "think about adding 256Mb".

Coming back to the proper issue, the solution given is previous posts (doing a single open when starting the soft and closing only when the soft is stoppped) is fine for me but I keep thinking that there is a memory leak somewhere because apparently when the connection to DB is closed, the memory won't be released before LabVIEW is shut down.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.