the code executes in msecs, but after 1-2 hrs the code execution time increases also the CPU goes to 50% consumption.
Now when i debug the code with probe, then it shows that sometime opening connection takes time, sometime execution of query, sometimes closing the database connection (time is calculated through the last update time),
As your code initially runs smoothly then slows down over time it may be worth tracing the executions steps using the "NI LabVIEW Execution Trace Toolkit." This toolkit should enable identification of problems that could negatively impact performace including reference leaks, memory allocation, unhandled errors, and subVI execution.
Are you opening and closing the connection every second? If so, my guess would be that you are suffering from TCP port exhaustion.
Port exhaustion is more of a code design issue than a LabVIEW one. Rather than open and close every second, open the DB and use a shift register in a while loop to perform your query every second against the existing session. If you must open and close every time, there are 2 ways to handle the issue (increasing the number of allowed ports and reducing the delay before they are closed and recycled).
In our implimentation, we chose to do both. We decreased the TCPTimedWaitDelay value from 240 seconds to 30 and increased the MaxUserPort setting from 5000 to 10000.
I have tried with Desktop Execution Trace toolkit but there is no reference leaks ans very less memory resize and i also have debugged it, no errors are there.
but i have observed one more thing, when the delay in execution starts, the delay continues to come until i restart labview.
so can we say that something is stored in the memory(buffer) and gets full after sometime and when i close labview then the buffer is initialised with null value.
It does seem that a "buffer" or area of memory is being filled resulting in the program lagging. Would it be possible to provide a code snippet or vi upload to provide a better idea on how your solution is implemented?
The situation seems to have been the same, repeated queries after many hours resulting in memory consumption. I would guess that this is related to the recordset object somehow not being disposed of correctly. One poster commented that his memory leak disappeared when he switched to a different LabVIEW database library (ADO Toolkit for LabVIEW).
I'm only sharing what I found. I can't comment on the library (never used it) or the accuracy; just a piece of data to help you in tracking down your problem.
