Family Historian User Group

In the last couple of weeks I've been using two copies of FH open at the same time, to compare two projects containing some duplicate branches of individuals that I am gradually merging into one tree. Each has an All Relatives diagram open for the part of the tree containing the duplicate people so that I can compare the information.

After an hour or so of use I'm getting an out of memory warning from Windows, telling me to shut down the FH programs (if I don't Windows just freezes and I have to do a hard reset of the PC to get things going again). I'm using W10 Pro, and have 16Gb of memory installed. The only other apps running are Windows Explorer and Avast anti virus. Digging around on the net for Windows 10 Low Memory Problems find this description https://superuser.com/questions/943175/ ... -available and the picture in the first post is almost exactly what I'm seeing, it's the "commit limit" that I'm reaching. I must admit to not understanding all of the detail in that post. Closing both copies of FH, it still takes a few minutes before the "commit charge" drops back to just a few Gb.

Has anyone else seen this problem? Is it FH misbehaving, or Windows or both?

I have this problem on One computer I run after the W10 creator update. Memory Hole effect comes in at 3:00pm each day. I have to restart.

Having read that article this is my understanding.

The Commit Charge is not actual memory use, but reserved memory use.
As FH uses its features, it makes sure it can obtain enough memory by increasing its Commit Charge.
It may never need it, but it is reserved just in case.
Maybe when a feature is closed, FH does not reduce its Commit Charge appropriately.

The Commit Charge Limit is the maximum allowed Commit Charge.
It is the sum of your PC RAM and the Pagefile that allows the RAM to be exceeded.
So the way to increase the Commit Charge Limit is to either increase RAM (that costs money) or increase Pagefile size (free).

In Windows 10, right-click Start and choose System (or Control Panel > System)
Then Advanced system settings top left, and on Advanced tab Performance Settings.
In the Performance Options, on Advanced tab in Virtual Memory it tells you the paging file size.
To alter it click Change clear the Automatically manage... tick box, and set the Custom size.

If that postpones the problem, then report the symptoms to Calico Pie.

davidm_uk wrote:In the last couple of weeks I've been using two copies of FH open at the same time, to compare two projects containing some duplicate branches of individuals that I am gradually merging into one tree.

Are you using Windows? I thought it wasn't possible to run multiple instances of FH. It seems I tried that a while back. Maybe it has to be different projects?

Never mind...I must have been thinking of another software, I just was able to do it. Perhaps Legacy Family Tree, since it definitely does not permit it, even if different versions.

Since I've got an SSD as my C: drive and there's plenty of spare space, I have set my max page file size at 32Gb (double what it was) and will see if that helps. I'll report back on the results.

I've seen some reports saying that this problem is a "feature" of W10 upgrades, which will/may go away with a clean install of W10 (and reinstalling all the applications). One day (or week) when I've nothing better to do I'll try this, maybe!

Ron, you can run two instances of FH, even on the same Project, but they will often 'interfere' with each other.
In much the same way AS and FH share the same Gedcom and if either detect a change they request a reload.
Also if you change FH customisations they may not 'flow' to the other instance without a Close & Open cycle.

tatewise wrote:Ron, you can run two instances of FH, even on the same Project.

Understood, I would only do it for viewing only on one of the instances anyway..thanks for confirming.

David, you promised to report back on your experiments.

Indeed I did Mike, thanks for the reminder.

Increasing the max page file size to 32Gb did allow me to use two instances of FH (with diagrams open in both) for a much longer time, but still a couple of times after extended sessions (4 hours or so) the out of memory warning appeared again. I used Sysinternals Process Explorer, with the System Information window open on the Memory tab, and I could see the System Commit graph slowly building up towards the maximum. In the end I just used a pragmatic solution and saved any changes I'd made then closed both instances of FH, let the "system" settle down for half an hour while I went for a cup of tea, then started again from where I'd left off. I could watch that graph gradually reducing to more normal levels, but it didn't happen instantly when I closed FH(s). It does seem to be related to having diagrams open, without them the problem didn't occur (or maybe it just took a lot longer than I monitored things for).

I've now finished the amalgamation of my two trees into one, so am unlikely to be stressing things in this way again for some time.

Great! That seems to confirm that increasing Page File size significantly postpones the Out of Memory error due to the Commit Charge and I have added that workaround to how_to:family_historian_installation_problems#errorout_of_memory|> Error: Out of Memory.

The limited memory explains the problem. Personally I let the page file get bigger than there here needed double my actual memory, but my normal PC has memory 32GB so I don't need it often, Windows 10 is a bit of a memory hog, so you might consider adding another stick of memory to the machine, alternately turn off the media caching on FH when you want to run multiple copies with lots of media. Turning off the pictures when working with diagrams will also help.

I already have 16Gb of memory installed, way more than the recommended amount. When I bought the PC the supplier queried why I want so much!

Jane, do you mean adjusting the Thumb Nail Cache as described in 'Out of Memory' when adding photo's. (15099)?

The physical RAM is not really the issue, because the Commit Charge is only reserved for potential use and rarely ever actually needed, but its upper Commit Charge Limit is the sum of the PC RAM and the Pagefile size as explained earlier near the start of this thread. So simply increasing the Pagefile size postpones the problem as confirmed by David. Allowing the Pagefile to increase automatically often does not help, especially if you have lots of RAM, because the actual memory usage is typically much lower than the Commit Charge reservation. Also FH does not appear to reduce the Commit Charge when it should.

I am sure Calico Pie could give a better explanation, since they appear to understand the problem, and it would be helpful if they could confirm whether the above workaround is the best solution at present.