[Glass] [GS/SS Beta] Scale to multiple nodes sharing a DB?

Dale K. Henrichs dale.henrichs at gemtalksystems.com
Fri Nov 15 09:59:20 PST 2013



----- Original Message -----
| From: "BrunoBB" <smalltalk at adinet.com.uy>
| To: glass at lists.gemtalksystems.com
| Sent: Friday, November 15, 2013 9:17:13 AM
| Subject: Re: [Glass] [GS/SS Beta] Scale to multiple nodes sharing a DB?
| 
| Hi Norbert,
| 
| "distributing an unpartitioned memory space over multiple hosts and
| modifying state only within transactions has severe limits."
| 
| Can you elaborate on this sentence ? What do you have in mind ?
| 
| -unpartitioned- can have multiple interpretations. Unpartitioned at
| hardware
| level, at logical level ?
| 
| I think you are talking about Shared Page Cache,  a SPC in a host has
| different objects that another SPC in other host (both attached to
| the same
| stone). In this case with your definition is partitioned or not ?

You are correct in surmising that the SPC does provide an additional level of partitioning that tends to organize references. GemStone also provides a clustering protocol for compacting object subgraphs on the pages ...
| 
| You will have a problem if your transactions are large in time (lot
| of
| changes without commits or aborts). You can solve this at application
| level.

Our customers tend to towards larger and larger SPCs and more and more cpus on a single machine for the abosulte fastest performance ... As is always the case the fastest access paths are always memory to memory if you have to go over a wire or hit disk then the performance impact is not transparent ...

So in the end, Norbert is correct that there are limitations to what can be achieved by adding multiple machines as opposed to increasing the size of a given machine ... but in the end it does depend upon the characteristics of the application and the size of the working set required ....

Dale


More information about the Glass mailing list