RAM used by Open Dental

[atd]

I'm seeing some high RAM usage with Open Dental. I don't know if this is a new problem - I just had users complaining about performance issues and noticed the terminal server at 97% RAM usage. Per the online user manual Open Dental uses 50MB of RAM, but I'm seeing a range between 65MB-155MB per user. When you have 20+ users on a terminal server, 3GB would be plenty if it was only using 50MB - but up that to 150MB and we have a problem. Server is Windows 2008, running Open Dental version 6.8.38. When I run it on my XP machine and watch the RAM, it climbs over 200MB and stays there for awhile, then eventually it goes back down to the 50MB range, then jumps around between 50-75MB. Anyone else seeing this?

[wjstarck]

Does the problem occur immediately, or after OD has been running awhile?

If you're not sure, shutdown all workstations, reboot the server, and then restart all the workstations, and then check the memory usage. If it takes awhile for the symptoms to recur, then that particular version of OD might have a memory leak (if memory serves (sorry for the bad pun :p), there was a memory leak in an earlier version of the 6.8 series). You might consider ugrading to 6.9, since it is now out of beta, and see if the problem goes away, since that might resolve the problem without alot of additional debugging.

HTH,

[jordansparks]

I was watching my Ram for a while a few days ago. I had two copies of OD running at once. Looked pretty good at about 20M and 50M. I looked up a few hours later, and the 50M had turned to 105M. Right now, I see 83M and 20M. The 83 climbed steadily to 89 and then dropped to 53. This is all with no use of the program by me. So what's happening is that background processes use memory, and then the garbage collector in dotNet clears out the unused objects. I would suggest quieting down the background processes by lengthening the refresh interval to maybe 15 or 20 seconds. Get rid of the appointment hover bubbles, too.

And we will start thinking of some instrumentation that could tell us how the memory is being used.

[jordansparks]

After spending hours analyzing the memory usage with a special tool, it's inconclusive. Memory goes up and down, but it didn't have any tendency to keep going up. On the test runs that I was doing, it was averaging 120MB, which is higher than I would have expected. Since the mangaged objects plus free space only added up to about 20MB, it looks like unmanaged objects are making up the difference. We will be looking into some of those as possible culprits.

[drtech]

so, does that mean the appt bubbles and refresh rate are causing more memory usage or not? (not sure what is managed and unmanaged)

[jordansparks]

Those two things were just suggestions to try. The appt bubbles were only suggested because it would reduce the graphical load on terminal server. Unmanaged objects include form controls, fonts, images, and a whole host of other things.

[jordansparks]

Found the problem. Took a few weeks of thinking hard about it. There's a timer that refreshes the waiting room grid once per second. Disabling that timer stopped the steady rise of memory consumption. I'm putting it on the bug list as:
Memory usage very high due to an inefficiency in the waiting room timer.

[jordansparks]

Fixed. Wow! The drop was very dramatic.

For those who are interested in the technical details: C# is managed. That means we don't have to worry about memory leaks. But, as with all software, they are phasing it in over many versions of Windows. That means that there are still some unmanaged objects that we deal with. I've always known about them and have been careful to dispose of Graphics objects, Streams, etc. But the MS documentation never made a big deal about disposing of Images. They do devote one or two lines to the topic, saying to dispose of an Image when done. But you never see it done in their examples.

We use Images for a technique called double buffering. In many places, it reduces flicker and creates a smooth eperience if you draw to an image, and then plop the image onto the screen. So the image is only used briefly and then we don't need it anymore. We do not rigorously dispose of our images. Although, based on the dramatic improvement in memory, we will be rigorously disposing of images from now on.

Why did we not notice it before now?
1. Over time, we have made more use of double buffering. It's a fancier technique.
2. This particular issue was noticeable because it was happening once per second, which was a little too fast for the automatic destructors built into C# to be able to handle.
3. Double buffering from a variety of places in the program is all adding up to make the total memory high. It's simply not an issue for smaller simpler programs.

What's very encouraging is that there are obvious other places where we can dispose of images to improve memory usage even more.

[drtech]

great discovery!

[jclaydds]

I have noticed some latency or sluggishness in Open Dental for last few weeks. Even called tech support to discuss the issue a week or so ago. We tried several things but no noticeable improvement. I was even thinking it might be an issue with my server and unrelated to Open Dental.

Just updated this morning to version 7.0.12 and noticed the memory issues that were addressed in this update. Open Dental seems much more responsive after the update. I am not seeing the same latency/sluggishness this morning but it is still early. Is this coincidental or just my imagination working overtime or could this memory issue have caused some of those symptoms with the program?

[jordansparks]

I'm not sure if the recent change would have had any effect on sluggishness. Maybe.

[wjstarck]

Great detective work, btw. All our instances of OD are now hovering stably at around 60MB...

[atd]

Fantastic - thank you for tracking this down and fixing it. I will upgrade this weekend and expect our terminal server will perform much better.

[jordansparks]

I did think of a way that it could have reduced sluggishness. If the garbage collector was having to work hard to destroy the images that were not being destroyed manually, then there could have been intermittent sluggishness.

[atd]

I upgraded to 6.9.32 on Sunday. I'm still seeing high RAM usage in some cases. Overall the RAM usage on the Terminal Server has gone from 95% down to 86%.
- Prior to the upgrade: 65MB-155MB per user
- After the upgrade: 23MB-122MB per user
Any other ideas as to why they're be such a big difference?

[jordansparks]

That amount of usage seems reasonable. It's well-known that a TS server will need significant RAM installed in order to scale up. RAM is not too expensive.

[atd]

I noticed today that the RAM being used by a few Open Dental terminal server sessions is significantly higher than it used to be. The majority are under 150MB, but I have one running steady at 320MB, another at 200MB, etc. We have 10GB of RAM on our terminal server, so we're not up to the max yet, but something seems wrong. Any idea what could be causing this? We're on version 7.6.33.