LabVIEW Page Faults Increase about 500/second

[Wiredup]

I'm running in the LabVIEW development environment with a program that monitors external data (all day long) using callbacks. Unfortunately, the program runs up the Page Fault counter about 500 Page Faults/Second. The Mem Usage counter remains essentually unchanges as the program runs all day.

The machine has plenty of physical memory (RAM) left over & available to the process (about 1 GB) and this level remains relatively unchanged as the page faults increase through the day.

I'm familiar with the concept of a memory leak, but not a "page fault leak". Is there a common programming mistake that can cause the PF counter to continually rise? Why the program causing page faults when there's plenty of available memory?

Thanks in advance for your ideas...

[smercurio_fc]

You're slightly misunderstanding that metric. A regular page fault is actually OK. All that it means is that Windows was trying to access data from RAM, and it wasn't there, as it was actually paged out to disk. Windows normally pages stuff out to disk. It's invalid page faults that you should be worried about.

[Wiredup]

Thanks for your reply and clarifying my misunderstanding(s). It is still not clear to me why windows would swap memory blocks to disk that are in use by this application since there's no shortage of physical memory available...but there's alot I don't understand about windows!

I ended up on this trail trying to find out why the program hangs after about 3.7 million page faults. Beyond this, the keyboard event detection in the program (as well as development menus) cease to work. Task Manager, End Task is the only way to stop the process once this happens. I don't know if app. hang and the page faults are related...but it was a first shot at trying to diagnose the problem.

[smercurio_fc]

Without knowing in detail what your program is doing I can only speculate. You said you're doing data monitoring using callbacks. This is a bit unusual. A callback involves the OS creating references. How frequent are these callbacks?

[Wiredup]

I've become way too familiar with the subtlties of callbacks in LabVIEW   with this project.

The callbacks are occuring from 1 to 10 times/second. There's 10 or so callback functions registered. The callback functions reside in an App-builder-generated DLL structured to match the C prototype of the caller's expectations. In some of these callback functions, there's a pointer passed to the callback. This pointer is used, along with length information, with the LV Runtime Engine function "MoveBlock" to copy the data at the pointer to LabVIEW-controlled memory space. The function is then closed, and the data is used from the copied location (now just a 'wire').

In the above, the pointer and known length are used to copy an array from the callback to a 'wire'. This array is flattened, tagged with the event type that generated the array, and flattened again to include in a LabVIEW User Event. The LVRT MoveBlock is marked as re-entrant (as is the callback DLL).

I'm guessing there's many ways this process could mess with Windows memory management...I just don't see how it could be made better to prevent the perpetual increase in Page Faults. Even though the PF's are not bad unto themselves, The quantity of PF's generated every second may be an indication of a bigger problem?

[smercurio_fc]

Well, just based on the description there seems to be a whole lot of memory management going on. Unfortunately, I'm not going to be able to help you further so I hope that someone else with a bit more knowledge in this specific area of LVRT will come along to help you.

[Wiredup]

No worries. I appreciate you taking the time to look it over.

[Gripster]

I ran into this problem a while back.  I solved it by placing case boxes around different program functions and turn them on/off while running to pin point the source.  The main cause of my PFs where coming from a shared variable library deployment call that constantly tried to deploy w/o closing the reference.  Actually I only needed to do this once at bootup or if not found.

But anyway, try the multiple case debugging technique and look for things like file opens that do not close.  Also you may have a huge number of abandon temporary files that need purged once you find the problem.

Good luck

RAM

[Wiredup]

Bill, thanks for your ideas. I used your case structure approach and narrowed down the problem. It turns out that all the fancy LVRT MoveBlock calls and callbacks are working just fine.

The pagefaults are being caused by the screen redraw of a meter object and waveform chart object! If I simply scroll the GUI so the updating chart and meter are off the visible screen, the pagefaults stop. Move them back onto the screen, and the pagefaults go back to their usual 500/second!

I seem to remember an "offscreenredraw" option (or some such thing). I'm off to see if I can dig that option up.

[Gripster]

Wow, thank's interesting.  How often is your code trying to update the indicator & graph?