Charlie Hoffpauir wrote:

Great comments Paul....

To answer a few questions you made about details I left out...

The OS was originally Win 7 64 bit Pro, now Win 10... took the plunge
and upgraded.

The computer is on a UPS... AC power out here in the country is far
from consistant, so virtually everything electronic is on a UPS (3
computers and 2 Dish network DVRs, each on it's own UPS)

My "C" drive is a SSD and all the data is on a couple of 7200 RPM SATA
drives. I was wondering if putting the large database files on an SSD
might speed things. These are large files for a home computer, 2.9 GB,
2.7 GB, 1.5 GB, etc. these are FileMaker Pro files, converted from
Access when the file size became too large for Access to handle. The
ones under 1 GB are all on MS Access. All of these as very simple
"flat" files, no complicated relationships.

Based on what you've said so far, I'm thinking that adding more memory
might not be the way I want to proceed.... I don't need the hassle of
trying to tune the memory, whereas adding an SSD for the data would
be really easy to implement.


I think moving the database files to the SSD is
a great first choice in experiments. As long as
the operations do mostly reads, and sparse writes,
everything should be fine, and you'll get any
speed boost that better I/O could provide.

*******

A more complicated experiment would be:

1) Buy a pair of DIMMs exactly like the ones you've got.
Another set of 2x8GB should not cost a lot today.

2) Do the tweaking and tuning, until memtest86+ and prime95
torture test (or any other tester that is known to be
good at certifying the memory) say the new setup is error free.

3) Install this, buy a license, and set the size to 16GB. Thus,
the newly installed RAM becomes a very fast RAMdisk. Load
the database files onto it.

http://memory.dataram.com/products-a...ftware/ramdisk

That product can write out the RAM contents at shutdown, but
you also have the option during the day, of doing anything
else you might like. Like, exit the database softwares
(so no files are busy or half-written), run a copy of
Macrium Reflect Free and make a backup. And so on. You can
backup and restore to the RAMDisk, because it behaves like
a block device. Only certain softwares, like perhaps older
Partition Managers, do not like the declared CHS geometry.
RAMDisks are not perfect emulations of SATA drives or anything.

My experience with the RAMDisk, is it might be twice as good
at the best of times. But not all operations benefit equally.

To give an example, when I ran my JKDefrag tests, and loaded
the RAMDisk with the C: partition from a real computer, one
kind of defrag when hosted in RAM, only did 1.5MB/sec. Terrible
performance. And another kind (defrag only, no optimize), ran
at 1GB/sec, and the disk was defragmented in a matter of just
ten seconds. It is the nature of the uneven performance,
that makes these RAMDisks such a loser. I cannot predict what
is going to happen. The same thing happened with running
VMs stored on the VHD file - VirtualBox ran no faster,
I was still seeing occasional 1.5MB/sec disk I/O to the RAMDisk.

So I have to mention this option for completeness, but
it's sheer lunacy with "real data" on it. If one of
my experiments runs amok here, nothing of value gets
lost :-) If yet another VM crashes and burns here, nobody
(not even me), cares.

Paul