On09.04.2010 16:17, Ronald Rudy wrote:
Memory is also a big consideration..
Hi Ronald,
Yes, it is; the page cache size, garbage collection and "memory for
other Derby stuff".
Since Derby's page cache is defined in number of pages, which can vary
in size, it's difficult to set a hard limit on the memory usage.
We've taken to running Derby using the network connector in a separate JVM
entirely running as a daemon/service, which gives a number of benefits
including exclusive rights to memory and the ability to connect to the database
on a test or live system and run queries..
I understand your point about exclusive memory rights. Getting the
balance right with Derby embedded inside the other app(s) can be tricky
in some cases.
Regarding your second point, are you aware of the "embedded server" mode?
This is where you have your main app connecting to Derby using the
embedded driver, and then you can start up a network server (permanent
or temporary) as well. Doing this requires a little bit of coding, or
setting a property when starting the main app (or rather before loading
the Derby driver).
Regards,
--
Kristian
-Ron
On Apr 9, 2010, at 9:59:59 AM, Kristian Waagan wrote:
On 09.04.2010 10:39, Rajesh Datla wrote:
Hi All,
I like to know the performance utilization of multi-processors on
a machine by Derby 10.3. Does Derby 10.3 utilize all CPU's on 8 CPU machine?.
Hi Rajesh,
I cannot give you any hard numbers for 10.3, but I have some general comments.
Hopefully someone else can pitch in with more details.
First, a fair bit of performance / scalability work has been done since 10.3.
The community is in the process of preparing for the 10.6 release [1]. I would
strongly suggest you use a newer release if possible.
Further, how much of the CPU Derby can utilize depends heavliy on the load,
with factors such as:
- number of concurrent connections / queries
- data contention
- access pattern
- IO subsystem (plus read/write ratio and page cache tuning )
The Derby engine is multi-threaded and should be able to use the available CPUs
when / if required. To find out the utilization rate you have to run a test
with your app / load.
Note that a single query will only use a single CPU / core.
I have run an industry standard benchmark on a 32-core machine, and Derby is
able to utilize the CPUs fairly well with that specific load and configuration
(75+%).
I have also seen syntetic benchmarks utilizing around 99% of the CPU (all data
in memory, read only, no data contention), but I doubt you'll manage that in a
real-world app :)
And finally, Derby has to use the CPUs for something useful as well - I'd
recommend a load test to see if Derby fulfills your requirements (then you can
come back to the list and ask questions if you see unexpected results).
Regards,
--
Kristian
[1] http://wiki.apache.org/db-derby/DerbyTenSixOneRelease
Regards
Raj
