VI causes high CPU load after several days of running

[johanneshoer]

Hello,

I have a strange problem. I have craeted a test bench control VI and it runs on five PCs, controling five test benches. All PCs have almost the same hardware, same motherboard, same CPU, etc.

Normaly the CPU load is around 50% when I run the VI, but at one PC the CPU load climbs up to 85% after several days (maybe one week) of continuous running and the PC is almost tied up - the VI execution becomes very slow (10 times slower) and the mouse only moves very slowly.

First I thought that the PC has a problem but the problem dissapears as soon as I stop and restart the VI!

I don't even have to terminate LabVIEW - only my VI and then everything is okay again.

The problem does not seem to occur at the other four PCs, but I can not tell for sure.

The task manager says only LabVIEW causes the CPU load - swap file utilisation is little.

Is there a way to analyze what causes the high CPU load?

I Use LabVIEW 7.1 professional

Operating System: Win XP (SP 2 or 3 I don't remember)

P.S. I have no loops without wait-functions.

[GerdW]

Hi Johannes,

"Is there a way to analyze what causes the high CPU load?"

Sure. Show your VI...

[DFGray]

If you are running in the development environment, you can use the profiler to find which VI is consuming all the time, then fix that VI.  Look in the LabVIEW help for information on how to use the profiler (it is in the Tools menu).  If you need to benchmark down to the node level in you code, the info in this post should get you there.

[altenbach]

Do all PCs have the same amount of RAM?

What is the memory use over time as seen by the windows taks manager. Does it increase gradually?

An increase in resource usage if often cause by sloppy programming.

• Do you grow arrays forever or constantly resize arrays in memory? (built array, insert into array, delete from array)
• Do you often create new references and never close them?
• ...

What does the program actually do? In my opinion, a constant 50% CPU load seems too high for my taste. It means it would not even be able to keep up on slightly older hardware. 😄

[johanneshoer]

@DFGray: Thank you for the link. I will try it.

@Altenbach: Yes, they have all the same amount of RAM. Memory use is low and does not increase - I have checked that.

The program is controlling a test bench and it is also processing some input data. There are three I/O-Modules and the slowest has a data rate of approx. 30 values/second. Processing all data takes approx. 10 - 15 ms, so the program "works" for 15 ms and waits 15 ms for new data, which corresponds more or less with a CPU load of 50%.

The Hardware is old. We bought the PCs three years ago with the least available configuration, which was: 2x2,4 Ghz, 2x1GB RAM... I just checked the data sheets of the PC and now I realize, that the PC where the problem occurs has only 2x512 GB RAM, the others have 2x1GB. Maybe I upgrading the RAM should be my first action...

@GerdW: I will updoad the VI, if we can not fix the problem in another way.

[johanneshoer]

I meant "We bought the PCs three years ago with the poorest/smallest/worst configuration available" 🙂 You know what I mean....

[Ben · Accepted solution]

---

@johanneshoer wrote:

...

the PC where the problem occurs has only 2x512 GB RAM, the others have 2x1GB. Maybe I upgrading the RAM should be my first action...

...

---

Assuming that is a typo the issue is you have run out physical memory and are reverting to virtual (which is 1000 X slower than real memory).

Christian nailed it.

Ben

[johanneshoer]

@Ben.

Of course I meant 2x512 MB

I pened the task manager and checked the swap file size (Auslagerungsdatei) and it did not grow, but stil I think the memory is to little and so I will change that...

Thanks! @all!