[Glass] Quick GemStone tunning

Hi guys. I know there are lots and lots of possible optimizations and tunning in GemStone (I do have the admin guide). 

Ohhh, I forgot....this gemstone would be running in a virtualbox image, so if there is some easy tunning there as well ;)

Mariano,

Sorry for the delay, but I took some holiday time in the last week or so and one of my rules was to not read any email until today:)

I've embedded my responses below ...

---

From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, November 26, 2013 1:09:08 PM
Subject: [Glass] Quick GemStone tunning

Hi guys. I know there are lots and lots of possible optimizations and tunning in GemStone (I do have the admin guide). 

But...I wondered...I have a 32GB RAM server with nothing else important running. Are there any parameter/flag/setting that I could easily increase to use GemStone as much as possible from my box?

I an easily build a test DB in which I create a lot of objects, so I was planning to do that and then use the app a bit to see how it behaves "out of the box" (without any special gemstone tunning).

I know SHR_PAGE_CACHE_SIZE_KB and GEM_TEMPOBJ_CACHE_SIZE

I don't really care about multiple concurrent requests now (so maybe increasing gems doesn't seem quite important) ... but I do care to perform fast, that is, use as much CPU and RAM as possible in the GLASS version. 

So...anything quick and dirty that I can set? 

Norbert correctly points out that the free license limits the SPC to 2GB and it is always a good idea to set your SPC as large as possible (limited by available RAM) as disk i/o is the number 1 performance issue. So the recommendation to use SSDs also makes sense.

You can also bump up the GEM_TEMPOBJ_CACHE_SIZE, but I would do that with care. I haven't done a lot of characterization myself, but my sense is that temp obj gc is driven off of the gem temp obj cache size and large gem temp obj cache size would allow more garbage objects to accumulate and increase the cost of temp obj gc, i.e., you might burn more cpu than necessary and CPU count is the second limitation of the free license  ... Soooo, I would recommend bumping up the size of the GEM_TEMPOBJ_CACHE_SIZE only when you determine that you need to as opposed to just bumping it up for the heck of it. If you routinely run out of memory in a Gem, then this is a good indication that your working set is larger than the temp obj cache, however, if you are in the middle of building a persistent graph, you could commit more frequently rather than bump up temp obj cache... In the proper choice of temp obj cache size is a function of trade offs ...

Another disk-related issue is that even though you are running on a virtual machine with virtual disks, it is not a bad idea to put your tranlogs on a disk partition that is separate isolated from other i/o ... your commit rate is correlated to how fast you can dump out tranlog records so isolating tranlog writes is a good idea. Linux has a tendency to favor reads over writes - it is willing to defer a disk write in favor of a disk read - which can lead to unnecessarily slow tranlog disk i/o ... I've hit this multiple times and the simple act of putting the tranlogs on a separate disk partition (even with virtual disks) has improved system throughput ...

Dale