Derby1961ResourceUsage2

Resource Usage in Derby

This page contains results found when investigating Derby's resource usage (DERBY-1961). If you have numbers you want to share, please add them to the Results section at the end.

Environment

• The Derby version tested is 10.2.1.6.
• Hardware: 2.4 GHz Dual-CPU AMD Opterons with 2 GB memory.
• OS: Solaris 10

• Configuration: 2 disks, one for log and one for data. Write cache is enabled . derby.storage.pageCacheSize=12500.

• Platform: Java SE 6.0 - build 1.6.0-rc-b102 or later

Load

The testing uses the load clients in DERBY-1961. They are able to perform three kinds of operations:

1. Single-record select operations. Each transaction reads one row from a table of 100000 rows (each row is around 100 bytes).
2. Single-record update operations. Each transaction updates one row in a table of 100000 rows (the same table as the select operations).
3. Join operations. Joins one table of 10000 rows with a table of 1000 rows. The result contains 1000 rows.

All three load types access the rows by primary key.

The tests are run as client/server tests so that the resource usage of the network server can be compared to the amount of resources used by the other parts of Derby. To make sure that the page cache can hold the entire database, increase the page cache size by starting the network server with -Dderby.storage.pageCacheSize=12500.

Modules

When looking at where Derby consumes resources, it helps to divide the code into modules or layers. Since the Derby code already is structured in packages, the modules could be defined in terms of the code packages:

Results

CPU and wall clock time

These results were obtained using a byte code instrumentation tool. The CPU times include both system and user CPU. The runs were done on a Solaris 10 machine with x86 hardware. Wall clock time were obtained using gethrtime and the CPU times using getrusage.
The network server was run with Java SE 6 (build 104, 64 bit Server VM). TestClient was configured with 30 seconds of warmup and 120 seconds runtime ("steady state").

Object allocations

These results have been found by running the JVM (Java SE 6.0 - build 1.6.0-rc-b102) with the -agentlib:hprof=heap=sites,... option and analysing the stack traces that were dumped. The numbers are not very accurate (in particular the join results), but they should at least give an impression of how much memory each module allocates.

Derby1961Objects has more details about what sorts of objects are allocated, the size of the allocated objects, and the number of allocations.

Garbage collection

The next table shows how much of the CPU is spent on garbage collection. Platform: Java SE 6.0 - build 1.6.0-rc-b103, Solaris 10, dual CPU. The numbers were collected using the GC probes in DTrace.

CPU spent on GC when the tests were run on a single-CPU machine:

System calls

Results found by logging all system calls on the database server with DTrace.

Context switches

The results in the following table have been found by logging all context switches on the database server with DTrace. There are two kinds of context switches:

• voluntary context switches, which means the thread gives the CPU to another thread voluntarily (e.g., blocking reads, calls to

  Object.wait() or attempts to lock a monitor which is locked by another thread)

• involuntary context switches, which means that a thread is preempted by the scheduler (because its time quantum has expired)

All the numbers are context switches per transaction.

Disk Access

The results in the following table have been found by logging all disk accesses on the database server with DTrace. There are two types of disk access (No reads were observed. Disk accesses for select and join have been omitted):

• Asynchronous write
• Synchronous write

All the numbers are per transaction.

Monitors and synchronization

The next table shows the number of times the test clients tried to enter a contended monitor per transaction (as reported by the hotspot:::monitor-contended-enter probe in DTrace), and the number of times the clients slept on a synchronization object per transaction (as reported by the sched:::sleep probe in DTrace).

Platform: Java SE 6.0 - build 1.6.0-rc-b103, Solaris 10, dual CPU.

Profiling Results

Running the test client for 900 sec with the embedded driver and 2 clients. Only the two working threads have been profiled. Only methods that use more than 1% User CPU or have a "significant" Sync Wait Time or Sync Wait Count, have been included.

Profiling was done using Sun Studio11 collect and analyzer

Method Calls

Derby1961MethodCalls shows which methods are called in a transaction and how often they are called.