db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-646) In-memory backend storage support
Date Tue, 24 Feb 2009 13:48:02 GMT

    [ https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676272#action_12676272
] 

Kristian Waagan commented on DERBY-646:
---------------------------------------

We now have two candidate solutions. How do we proceed?

I would very much like to get an in-memory back end included in the upcoming
10.5 release. In my opinion this should be pretty safe, as almost no existing
code is modified and the user has to take an active step to use the in-memory
back end.

To start mapping the performance characteristics of the two solutions, I ran
some of the performance tests we have. Note that these are based on only a few
runs, and a run time of 60 seconds only (pluss 30 seconds warmup). The numbers
are average tps (transactions per second).
There is some variation in the tests, so where the numbers differ only by a very
small percentage, I think we can assume the performance is comparable for now.

Hardware #1: 32 hardware execution threads, 1200 MHz.
                sr_update   sr_select   bank_tx
1 thread
  memory         1963        3059         823
  vfmem          2307        3753         878
8 threads
  memory         7662       14321        2163
  vfmem         12692       17695        2294
32 threads
  memory         7357       13984        2076
  vfmem         12219       16546        2144

Hardware #2: Dual core Opteron, 2.4 GHz
                sr_update   sr_select   bank_tx
1 thread
  memory        12257       20295        5123
  vfmem         12288       20657        5189
4 threads
  memory        15064       32117        6120
  vfmem         15857       32629        6115
8 threads
  memory        16682       31257        5767
  vfmem         16357       31361        5775


Hardware #3: 2xDual core Opteron, 2.8 GHz
                sr_update   sr_select   bank_tx
1 thread
  memory        13548       22184         5805
  vfmem         13705       21770         5765
4 threads
  memory        29019       57861        10443
  vfmem         29727       58053        10479
8 threads
  memory        26348       46580         9372
  vfmem         26676       46805         9347
16 threads
  memory        24500       44249         8976
  vfmem         24883       43832         9014


Hardware #2: Dual core Opteron, 2.4 GHz, sr_update, page cache size
                40      1000    15000
1 thread
  memory         9932   12234   19207
  vfmem         10075   12223   18995
8 threads
  memory        12898   16540   26393
  vfmem         13148   16662   28017

Hardware #2: Dual core Opteron, 2.4 GHz, sr_update, page size
Page cache size |     40    |   |    1000   |
                4 KB    32 KB   4 KB    32 KB
1 thread
  memory         9902    2902   12369   20168
  vfmem         10342    3247   12059   19801  
8 threads
  memory        12926    3599   16523   27333
  vfmem         13261    4059   16592   28361

As far as I can see from these simple performance tests, the only configuration where the
two solutions differs significantly, is when running on a CMT (chip multi threading) machine.
Of the loads I have tested, this is most clearly visible with update load.
I have not investigated this further.

Another thing one could look into, is the memory usage of the two solutions.


> In-memory backend storage support
> ---------------------------------
>
>                 Key: DERBY-646
>                 URL: https://issues.apache.org/jira/browse/DERBY-646
>             Project: Derby
>          Issue Type: New Feature
>          Components: Store
>         Environment: All
>            Reporter: Stephen Fitch
>         Attachments: derby-646-1a-raw-compiles.diff, derby-646-1a-raw-compiles.stat,
derby-646-20090222.diff, derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff, derby-646-2a-vfmem_first_rev.stat,
svn.diff
>
>
> To allow creation and modification of databases in-memory without requiring disk access
or space to store the database.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message