See my other email titled "Really need some help here please. I think I am having a problem with some sort of caching in Derby". I think these are related and I think the page cache size is a red-herring, in this case when in fact, it is probably something else cached in Derby that is being forced to be released by the forced garbage collection.
-----Original Message-----
From: Bryan Pendleton [mailto:
bpendleton.derby@...]
Sent: Monday, March 26, 2012 10:09 AM
To:
derby-dev@...
Subject: Re: Yet another performance question, this time on derby.storage.pageCacheSize
> I forced a garbage collection, and then ran the queries. The time went down to on the order of seconds.
This is a fascinating result, though I'm not really sure what it means.
I don't think I've ever given a JVM permission to use 8 GB before.
I'm not sure you can conclude it's directly related to the page cache, though.
If I'm doing the math correctly, only 256MB of that memory was page cache; it's hard to know what the other 7.75 GB was being used for.
The fact that your system runs just fine on a configuration that's 1/16th the size, seems to suggest that 95% of the memory in that larger experiment was unnecessary for your current workload.
It's hard to tell what the system was doing with all those extra resources, though.
But your forced JVM observation indicates that, whatever it was doing, it wasn't doing it very efficiently :)
With modern VMs you can force a heap dump, and then analyze it later at your leisure.
So you could repeat the experiment (though maybe not going all the way to 8 GB, maybe just 1GB or 2GB), and then take a dump of that JVM and try to figure out what's occupying memory, using a heap analysis tool (try the Eclipse memory analyzer, it's a great tool).
thanks,
bryan
