Smalltalk › Gemtalk › GLASS

performance testing

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 9 messages Options
Nick
Reply | Threaded
Open this post in threaded view
♦
♦
|

performance testing

Nick
Hi,

I'm running Gemstone on a VPS server with 2G RAM. I've experimented with running 1, 3 and 6 Gems to get an idea of how that will effect performance. What surprised me is that the result for pages/s when running 1 Gem seems to be similar if not sometimes faster than when running 3 Gems. When trying 6 Gems page/s dropped - presumably due to CPU or RAM contention.
I wondered if my configuration might be sub-optimal and also thought I'd retest with the new license key to allow Gemstone to work with greater RAM (http://seaside.gemstone.com/docs/GLASS-Announcement.htm). 
Is it possible to download a new licence key which include the increased limits? I couldn't find a link to the key from seaside.gemstone.com and tried downloading the installations but they don't appear to have an updated key.

I'm using apache bench and testing as follows:

ab -kc 50 -t 100 -n 100  http://getitmade.com/getitmade

1 Gem: Requests per second:    7.11 [#/sec] (mean)
3 Gems: Requests per second:    6.33 [#/sec] (mean)
6 Gems: Requests per second:    5.96 [#/sec] (mean)

I was surprised by this result and wondered if my web server was distributing the results between the Gems. To verify I added the following debugging to: WAServerAdaptor>>process: 
(ObjectLogEntry debug: 'incoming on port: ' object: aNativeRequest connection server port) addToLog.

I could clearly see that the my front end server (Nginx) was distributing the requests on a round-robin basis to the Gems.

Any thoughts on why I'm not seeing a significant improvement in through-put (in-fact a degradation) when testing with 1 Gem vs 3 Gems?

Thanks

Nick

----

For completeness the full output of Apache bench:

1 Gem:
----------
 
Server Software:        nginx/0.7.65
Server Hostname:        getitmade.com
Server Port:            80

Document Path:          /getitmade
Document Length:        32689 bytes

Concurrency Level:      50
Time taken for tests:   14.069 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    100
Total transferred:      3312512 bytes
HTML transferred:       3296251 bytes
Requests per second:    7.11 [#/sec] (mean)
Time per request:       7034.694 [ms] (mean)
Time per request:       140.694 [ms] (mean, across all concurrent requests)
Transfer rate:          229.92 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   48  51.2     46     130
Processing:   739 5258 2481.7   6322   10226
Waiting:      634 5165 2493.1   6247   10158
Total:        787 5307 2488.4   6322   10226

Percentage of the requests served within a certain time (ms)
  50%   6322
  66%   6620
  75%   6796
  80%   7271
  90%   8697
  95%   9410
  98%   9661
  99%  10226
 100%  10226 (longest request)

3 Gems:
------------

Server Software:        nginx/0.7.65
Server Hostname:        getitmade.com
Server Port:            80

Document Path:          /getitmade
Document Length:        32689 bytes

Concurrency Level:      50
Time taken for tests:   16.132 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    100
Total transferred:      3285000 bytes
HTML transferred:       3268900 bytes
Requests per second:    6.20 [#/sec] (mean)
Time per request:       8065.876 [ms] (mean)
Time per request:       161.318 [ms] (mean, across all concurrent requests)
Transfer rate:          198.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   19  35.6      0     112
Processing:   283 3093 2097.5   2594   13037
Waiting:      194 3024 2094.2   2530   12944
Total:        330 3112 2109.1   2595   13116

Percentage of the requests served within a certain time (ms)
  50%   2595
  66%   2755
  75%   2888
  80%   2965
  90%   5492
  95%   5830
  98%  12193
  99%  13116
 100%  13116 (longest request)

6 Gems:
------------
Server Software:        nginx/0.7.65
Server Hostname:        getitmade.com
Server Port:            80

Document Path:          /getitmade
Document Length:        32689 bytes

Concurrency Level:      50
Time taken for tests:   16.766 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    100
Total transferred:      3341472 bytes
HTML transferred:       3325050 bytes
Requests per second:    5.96 [#/sec] (mean)
Time per request:       8383.223 [ms] (mean)
Time per request:       167.664 [ms] (mean, across all concurrent requests)
Transfer rate:          194.62 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   49  51.3     47     126
Processing:  2842 6464 1644.9   6762   10173
Waiting:     2695 6318 1646.7   6633   10024
Total:       2904 6512 1645.8   6762   10297

Percentage of the requests served within a certain time (ms)
  50%   6762
  66%   7283
  75%   7580
  80%   7633
  90%   8330
  95%   9355
  98%  10291
  99%  10297
 100%  10297 (longest request)
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Dale Henrichs
Nick,

Ah the wonderful world of performance testing! The good news is that
GemStone has pretty good support for monitoring a large number of system
variables that can affect performance. The bad news is that there are a
large number of variables that can affect performance.

The first thing to do is to use statmonitor. I typically use the
following command to start statmonitor:

   statmonitor <stonename> -A -i 1 -u 0 -z &

Once you've started statmonitor, you can view the output with vsd:

   vsd <statmon file> &

In vsd I select 'File>>Auto Update' so that I can watch the plots in
real time.

Select 'Template>>New Template Chart>>CacheMix and wait for the new
graph to finish displaying. There should be about 12 or so different
stats displayed. Click on the 'FreeFrameCount' stat and select the
'Line>>Graph on LeftAxis' menu item ... you'll get a relatively boring
graph....

Now start your ab run.

You'll see that the FreeFrameCount starts dropping and the
DataPagesWrittenByGem stat climbing along with a couple of the other
stats. As long as the FreeFrameCount isn't pinned against the bottom
your Shared Page Cache (SPC) is big enough ... If the FreeGrameCount is
pinned against the bottom increasing the SPC size is just one of the
things that you can do (although depending upon what else is going on,
increasing the number of AIO page servers may need to be done or ...).

Now go back to the main vsd window, and select all of the Topaz gems in
the top pane and select 'SessionStat0' in the bottom pane. For Seaside
SessionStat0 is a gem by gem count of HTTP requests processed. In the
top pane, use the right button and make sure that the 'Combine' item is
not selected. Press the 'New Chart' button and you'll get a graph where
three of the lines (assuming you are using 3 gems) have changed value.
Next, select the 'Combine' item and press 'New Chart' and you'll get a
chart with one line on it (the sum of the  SessionStat0 stat for all
selected gems). Select the 'SessionStat0' in the bottom pane and click
on the 'No Filter' button and select 'PerSecond'. This will give you
your overall HTTP request handling rate and if you hover over the peak
of the stats, the number that shows up in the Y: box at top of chart
should match the number that ab reported as the average.

If you select 'PerSecond' for each of the gems in the multi-gem chart
you will get a chance to see the HTTP request rate for each individual
gem (and tell if the requests are truly balanced or not).

The next thing to do is to go back to vsd and select the entry whose
name matches the name of the system on which you are running ... the
type will be XXX_System. Then select PercentCpuActive in the bottom pane
and press 'New Chart'. This will give you an idea if your system is cpu
saturated (remember that on multi cpu systems, you will be saturated if
you've consumed 1 or 2 cpus depending upon the license that you are using).

If you poke around you will see that there are literally hundreds of
stats for all of the gemstone processes, plus your disks plus your
ethernet cards ... more than I can cover here - in fact we put on a 3
day course that covers performance tuning.

As far as benchmarking goes, I think that 100 samples is way to small.
You _should_ run a bench mark that lasts at least twice as long as your
session expiration time so that you can get an idea of what your steady
state performance will be.

Then there are different types of benchmarks ... With the way that ab
was configured, you were saturation bombing your site ...  hitting your
site with ab means that every hit is a new session ... not
representative of a real load, but still useful:

   - with 50 concurrent requests and no inter-request delays you are
     saturating the system with requests so you would expect to see the
     CPU, Disk, or SPC become the bottle neck and then tune by first
     going to raw disks for tranlogs to start addressing disk bound
     problems or using a larger SPC or adding more cpus.

50 concurrent requests doesn not equate to 50 concurrent _users_ since
real users don't click as fast as ab can click.

seige gives you the ability to add inter-request delays to allow you to
simulate real user loads, so I'd say that using siege is a good idea.
But you're still hitting a single URL (or collection of URLs) each of
which creates a new session .... jcrawler will follow links using the
same url, but it will attempt to do so concurrently which isn't
representative either ... I haven't found anything that is satisfactory
for load testing seaside.

At around 10 requests/second that means that you are getting nearly 1
million hits per day, which is a pretty good volume and it would
probably make sense that you'd want to spend a little money on hardware
to get better performance ...


There's more...

Dale

On 10/19/2010 12:20 AM, Nick Ager wrote:

> Hi,
>
> I'm running Gemstone on a VPS server with 2G RAM. I've experimented with
> running 1, 3 and 6 Gems to get an idea of how that will effect
> performance. What surprised me is that the result for pages/s when
> running 1 Gem seems to be similar if not sometimes faster than when
> running 3 Gems. When trying 6 Gems page/s dropped - presumably due to
> CPU or RAM contention.
> I wondered if my configuration might be sub-optimal and also thought I'd
> retest with the new license key to allow Gemstone to work with greater
> RAM (http://seaside.gemstone.com/docs/GLASS-Announcement.htm).
> Is it possible to download a new licence key which include the increased
> limits? I couldn't find a link to the key from seaside.gemstone.com
> <http://seaside.gemstone.com> and tried downloading the installations
> but they don't appear to have an updated key.
>
> I'm using apache bench and testing as follows:
>
> ab -kc 50 -t 100 -n 100 http://getitmade.com/getitmade
>
> 1 Gem: Requests per second:    7.11 [#/sec] (mean)
> 3 Gems: Requests per second:    6.33 [#/sec] (mean)
> 6 Gems: Requests per second:    5.96 [#/sec] (mean)
>
> I was surprised by this result and wondered if my web server was
> distributing the results between the Gems. To verify I added the
> following debugging to: WAServerAdaptor>>process:
> (ObjectLogEntry debug: 'incoming on port: ' object: aNativeRequest
> connection server port) addToLog.
>
> I could clearly see that the my front end server (Nginx) was
> distributing the requests on a round-robin basis to the Gems.
>
> Any thoughts on why I'm not seeing a significant improvement in
> through-put (in-fact a degradation) when testing with 1 Gem vs 3 Gems?
>
> Thanks
>
> Nick
>
> ----
>
> For completeness the full output of Apache bench:
>
> 1 Gem:
> ----------
> Server Software:        nginx/0.7.65
> Server Hostname: getitmade.com <http://getitmade.com>
> Server Port:            80
>
> Document Path:          /getitmade
> Document Length:        32689 bytes
>
> Concurrency Level:      50
> Time taken for tests:   14.069 seconds
> Complete requests:      100
> Failed requests:        0
> Write errors:           0
> Keep-Alive requests:    100
> Total transferred:      3312512 bytes
> HTML transferred:       3296251 bytes
> Requests per second:    7.11 [#/sec] (mean)
> Time per request:       7034.694 [ms] (mean)
> Time per request:       140.694 [ms] (mean, across all concurrent requests)
> Transfer rate:          229.92 [Kbytes/sec] received
>
> Connection Times (ms)
>                min  mean[+/-sd] median   max
> Connect:        0   48  51.2     46     130
> Processing:   739 5258 2481.7   6322   10226
> Waiting:      634 5165 2493.1   6247   10158
> Total:        787 5307 2488.4   6322   10226
>
> Percentage of the requests served within a certain time (ms)
>    50%   6322
>    66%   6620
>    75%   6796
>    80%   7271
>    90%   8697
>    95%   9410
>    98%   9661
>    99%  10226
>   100%  10226 (longest request)
>
> 3 Gems:
> ------------
>
> Server Software:        nginx/0.7.65
> Server Hostname: getitmade.com <http://getitmade.com>
> Server Port:            80
>
> Document Path:          /getitmade
> Document Length:        32689 bytes
>
> Concurrency Level:      50
> Time taken for tests:   16.132 seconds
> Complete requests:      100
> Failed requests:        0
> Write errors:           0
> Keep-Alive requests:    100
> Total transferred:      3285000 bytes
> HTML transferred:       3268900 bytes
> Requests per second:    6.20 [#/sec] (mean)
> Time per request:       8065.876 [ms] (mean)
> Time per request:       161.318 [ms] (mean, across all concurrent requests)
> Transfer rate:          198.86 [Kbytes/sec] received
>
> Connection Times (ms)
>                min  mean[+/-sd] median   max
> Connect:        0   19  35.6      0     112
> Processing:   283 3093 2097.5   2594   13037
> Waiting:      194 3024 2094.2   2530   12944
> Total:        330 3112 2109.1   2595   13116
>
> Percentage of the requests served within a certain time (ms)
>    50%   2595
>    66%   2755
>    75%   2888
>    80%   2965
>    90%   5492
>    95%   5830
>    98%  12193
>    99%  13116
>   100%  13116 (longest request)
>
> 6 Gems:
> ------------
> Server Software:        nginx/0.7.65
> Server Hostname: getitmade.com <http://getitmade.com>
> Server Port:            80
>
> Document Path:          /getitmade
> Document Length:        32689 bytes
>
> Concurrency Level:      50
> Time taken for tests:   16.766 seconds
> Complete requests:      100
> Failed requests:        0
> Write errors:           0
> Keep-Alive requests:    100
> Total transferred:      3341472 bytes
> HTML transferred:       3325050 bytes
> Requests per second:    5.96 [#/sec] (mean)
> Time per request:       8383.223 [ms] (mean)
> Time per request:       167.664 [ms] (mean, across all concurrent requests)
> Transfer rate:          194.62 [Kbytes/sec] received
>
> Connection Times (ms)
>                min  mean[+/-sd] median   max
> Connect:        0   49  51.3     47     126
> Processing:  2842 6464 1644.9   6762   10173
> Waiting:     2695 6318 1646.7   6633   10024
> Total:       2904 6512 1645.8   6762   10297
>
> Percentage of the requests served within a certain time (ms)
>    50%   6762
>    66%   7283
>    75%   7580
>    80%   7633
>    90%   8330
>    95%   9355
>    98%  10291
>    99%  10297
>   100%  10297 (longest request)
>
>
>
>

Monty Williams-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Monty Williams-3
In reply to this post by Nick
On 10/19/2010 12:20 AM, Nick Ager wrote:
Is it possible to download a new licence key which include the increased limits? I couldn't find a link to the key from seaside.gemstone.com and tried downloading the installations but they don't appear to have an updated key.

Nick, larger keys are at http://seaside.gemstone.com/etc/ -- we just haven't published a new GLASS version since ESUG. When we do, it will have the larger keyfile.

-- Monty
Nick
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Nick
Hi Monty,

On 26 October 2010 01:44, Monty Williams <[hidden email]> wrote:
On 10/19/2010 12:20 AM, Nick Ager wrote:
Is it possible to download a new licence key which include the increased limits? I couldn't find a link to the key from seaside.gemstone.com and tried downloading the installations but they don't appear to have an updated key.

Nick, larger keys are at http://seaside.gemstone.com/etc/ -- we just haven't published a new GLASS version since ESUG. When we do, it will have the larger keyfile.

I finally got round to downloading the key:

cd /opt/gemstone/product/seaside/etc
mv gemstone.key gemstone.key.orginal
mv gemstone.key-GLASS-Linux-2CPU.txt gemstone.key


What I find is that when I restart GemStone the "startGemstone" script doesn't return. It appears to hang at the line:

startstone[Info]: Log file is '/opt/gemstone/log/seaside.log'.

Disconcertingly I never see:
startstone[Info]: GemStone server 'seaside' has been started.
 
However if I replace the original key Gemstone appears to startup as expected.

Is there some extra configuration I need to perform?

Thanks

Nick
Monty Williams-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Monty Williams-3
Hi Nick,

You just changed the wrong key. Unless there is a different keyfile location specified in your conf file, the default location is $GEMSTONE/sys/gemstone.key

-- Monty


On Nov 12, 2010, at 12:37 PM, Nick Ager wrote:

Hi Monty,

On 26 October 2010 01:44, Monty Williams <[hidden email]<mailto:[hidden email]>> wrote:
On 10/19/2010 12:20 AM, Nick Ager wrote:
Is it possible to download a new licence key which include the increased limits? I couldn't find a link to the key from seaside.gemstone.com<http://seaside.gemstone.com/> and tried downloading the installations but they don't appear to have an updated key.

Nick, larger keys are at http://seaside.gemstone.com/etc/ -- we just haven't published a new GLASS version since ESUG. When we do, it will have the larger keyfile.

I finally got round to downloading the key:

cd /opt/gemstone/product/seaside/etc
wget http://seaside.gemstone.com/etc/gemstone.key-GLASS-Linux-2CPU.txt
mv gemstone.key gemstone.key.orginal
mv gemstone.key-GLASS-Linux-2CPU.txt gemstone.key


What I find is that when I restart GemStone the "startGemstone" script doesn't return. It appears to hang at the line:

startstone[Info]: Log file is '/opt/gemstone/log/seaside.log'.

Disconcertingly I never see:
startstone[Info]: GemStone server 'seaside' has been started.

However if I replace the original key Gemstone appears to startup as expected.

Is there some extra configuration I need to perform?

Thanks

Nick


Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Dale Henrichs
For Seaside the location is defined in defSeaside source script and in
2.4.4.1 is defined as:

   $GEMSTONE/seaside/etc/gemstone.key

So that looks like the correct location ... I haven't actually tried the
new key, so it does sound like somethings wrong with the key ...
interesting that you're not getting any error messages in stone log...

Dale

On 11/12/2010 01:13 PM, Monty Williams wrote:

> Hi Nick,
>
> You just changed the wrong key. Unless there is a different keyfile location specified in your conf file, the default location is $GEMSTONE/sys/gemstone.key
>
> -- Monty
>
>
> On Nov 12, 2010, at 12:37 PM, Nick Ager wrote:
>
> Hi Monty,
>
> On 26 October 2010 01:44, Monty Williams<[hidden email]<mailto:[hidden email]>>  wrote:
> On 10/19/2010 12:20 AM, Nick Ager wrote:
> Is it possible to download a new licence key which include the increased limits? I couldn't find a link to the key from seaside.gemstone.com<http://seaside.gemstone.com/>  and tried downloading the installations but they don't appear to have an updated key.
>
> Nick, larger keys are at http://seaside.gemstone.com/etc/ -- we just haven't published a new GLASS version since ESUG. When we do, it will have the larger keyfile.
>
> I finally got round to downloading the key:
>
> cd /opt/gemstone/product/seaside/etc
> wget http://seaside.gemstone.com/etc/gemstone.key-GLASS-Linux-2CPU.txt
> mv gemstone.key gemstone.key.orginal
> mv gemstone.key-GLASS-Linux-2CPU.txt gemstone.key
>
>
> What I find is that when I restart GemStone the "startGemstone" script doesn't return. It appears to hang at the line:
>
> startstone[Info]: Log file is '/opt/gemstone/log/seaside.log'.
>
> Disconcertingly I never see:
> startstone[Info]: GemStone server 'seaside' has been started.
>
> However if I replace the original key Gemstone appears to startup as expected.
>
> Is there some extra configuration I need to perform?
>
> Thanks
>
> Nick
>
>
Nick
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Nick
Hi

... interesting that you're not getting any error messages in stone log...


Thanks for the gentle hint :-)

I've tried the key again and this time it works - so perhaps it was nothing to do with the key.

I've examined seaside.log and noticed that when the startGemstone script appears to hang the log stop at "Attaching the Shared Cache using Stone name: seaside" without proceeding to: "Successfully started 1 free frame page servers"

Two snipets are show below, both with the new key; the first is the startup when the startGemstone script appears to hang; the second is when it all appears well:

--- 12/11/10 18:23:57 UTC ---
 _____________________________________________________________________________
|    Key file:  /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/etc/gemstone.key
| GemStone ID:  Free GS/S Web Edition                                         |
| LICENSED TO:  GemStone Seaside Community                                    |
|  KEY ORIGIN:  0x809c3427 (a Sun Sparc Solaris)                              |
|_____________________________________________________________________________|
WARNING: Argument size is too small to represent FileNames. (4095 vs 2048)

========================================================================
    Now starting GemStone monitor.

 _____________________________________________________________________________
|     SESSION CONFIGURATION: The maximum number of concurrent sessions is 41. |
|_____________________________________________________________________________|

    Attaching the Shared Cache using Stone name: seaside




=============================================================================

--- 12/11/10 21:51:26 UTC ---
_____________________________________________________________________________
|    Key file:  /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/etc/gemstone.key
| GemStone ID:  Free GS/S Web Edition                                         |
| LICENSED TO:  GemStone Seaside Community                                    |
|  KEY ORIGIN:  0x809c3427 (a Sun Sparc Solaris)                              |
|_____________________________________________________________________________|
WARNING: Argument size is too small to represent FileNames. (4095 vs 2048)

========================================================================
   Now starting GemStone monitor.

_____________________________________________________________________________
|     SESSION CONFIGURATION: The maximum number of concurrent sessions is 41. |
|_____________________________________________________________________________|

   Attaching the Shared Cache using Stone name: seaside
   Successfully started 1 free frame page servers.

   -------------------------------------------------------
   Summary of Configured Transaction Logs
     Directory   0:
       configured name $GEMSTONE_DATADIR/
       expanded name /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/
       configuredSize 1000 MB
     Directory   1:
       configured name $GEMSTONE_DATADIR/
       expanded name /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/
       configuredSize 1000 MB
   -------------------------------------------------------

   Extent #0
   -----------
   Filename = !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
   Maximum size = NONE
   File size = 58 Mbytes = 3712 pages
   Space available = 7 Mbytes = 478 pages

   Totals
   ------
   Repository Size = 58 Mbytes = 3712 pages
   Free Space = 7 Mbytes = 478 pages
   ---------------------------------------------------


   Repository startup statistics:
       Pages Need Reclaiming =3
       Free Oops=7683
       Oop Number High Water Mark=403915
       Possible Dead Objects=0
       Dead Objects=0
       Epoch Transaction Count=0
       Epoch New Objects Union=0
       Epoch Written Objects Union=0
       Epoch DependencyMap Objects Union=0

   Repository startup is from checkpoint = (fileId 2, blockId 20527)


   Opening a transaction log file for read.
      filename = /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/tranlog2.dbf

   Opening a transaction log file for write.
      filename = /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/tranlog2.dbf

   Starting user services with name = !#server!seaside
--- 12/11/10 21:51:27.562 UTC :
   Starting a Page Manager Gem process
--- 12/11/10 21:51:27.592 UTC :    Session 1 with processId 24992 is now the Page Manager Gem.

--- 12/11/10 21:51:28.568 UTC :
   Starting a Reclaim Gem process for extents 0 to 0
--- 12/11/10 21:51:28.582 UTC :
   Starting a Admin Gem process
--- 12/11/10 21:51:28.624 UTC :
   Starting a SymbolCreation Gem process

   Session 2 with processId 24999 is now the Page Reclaim Gem for
   extents 0 through 0.

   Session 3 with processId 25000 is now the Admin Gem.
--- 12/11/10 21:51:28.703 UTC :    Session 4 with processId 25004 is now the Symbol Creation Gem.
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: performance testing

Dale Henrichs
Nick,

Yes that would be a place where it could hang ... there might be more
info in the page server logs (*pgsvr*.log)...

Dale

On 11/12/2010 02:25 PM, Nick Ager wrote:

> Hi
>
>     ... interesting that you're not getting any error messages in stone
>     log...
>
>
> Thanks for the gentle hint :-)
>
> I've tried the key again and this time it works - so perhaps it was
> nothing to do with the key.
>
> I've examined seaside.log and noticed that when the startGemstone script
> appears to hang the log stop at "Attaching the Shared Cache using Stone
> name: seaside" without proceeding to: "Successfully started 1 free frame
> page servers"
>
> Two snipets are show below, both with the new key; the first is the
> startup when the startGemstone script appears to hang; the second is
> when it all appears well:
>
> --- 12/11/10 18:23:57 UTC ---
>   _____________________________________________________________________________
> |    Key file:
>   /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/etc/gemstone.key
> | GemStone ID:  Free GS/S Web Edition
>        |
> | LICENSED TO:  GemStone Seaside Community
>       |
> |  KEY ORIGIN:  0x809c3427 (a Sun Sparc Solaris)
>       |
> |_____________________________________________________________________________|
> WARNING: Argument size is too small to represent FileNames. (4095 vs 2048)
>
> ========================================================================
>      Now starting GemStone monitor.
>
>   _____________________________________________________________________________
> |     SESSION CONFIGURATION: The maximum number of concurrent sessions
> is 41. |
> |_____________________________________________________________________________|
>
>      Attaching the Shared Cache using Stone name: seaside
>
>
>
>
> =============================================================================
>
> --- 12/11/10 21:51:26 UTC ---
> _____________________________________________________________________________
> |    Key file:
>   /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/etc/gemstone.key
> | GemStone ID:  Free GS/S Web Edition
>        |
> | LICENSED TO:  GemStone Seaside Community
>       |
> |  KEY ORIGIN:  0x809c3427 (a Sun Sparc Solaris)
>       |
> |_____________________________________________________________________________|
> WARNING: Argument size is too small to represent FileNames. (4095 vs 2048)
>
> ========================================================================
>     Now starting GemStone monitor.
>
> _____________________________________________________________________________
> |     SESSION CONFIGURATION: The maximum number of concurrent sessions
> is 41. |
> |_____________________________________________________________________________|
>
>     Attaching the Shared Cache using Stone name: seaside
>     Successfully started 1 free frame page servers.
>
>     -------------------------------------------------------
>     Summary of Configured Transaction Logs
>       Directory   0:
>         configured name $GEMSTONE_DATADIR/
>         expanded name
> /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/
>         configuredSize 1000 MB
>       Directory   1:
>         configured name $GEMSTONE_DATADIR/
>         expanded name
> /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/
>         configuredSize 1000 MB
>     -------------------------------------------------------
>
>     Extent #0
>     -----------
>     Filename =
> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>     Maximum size = NONE
>     File size = 58 Mbytes = 3712 pages
>     Space available = 7 Mbytes = 478 pages
>
>     Totals
>     ------
>     Repository Size = 58 Mbytes = 3712 pages
>     Free Space = 7 Mbytes = 478 pages
>     ---------------------------------------------------
>
>
>     Repository startup statistics:
>         Pages Need Reclaiming =3
>         Free Oops=7683
>         Oop Number High Water Mark=403915
>         Possible Dead Objects=0
>         Dead Objects=0
>         Epoch Transaction Count=0
>         Epoch New Objects Union=0
>         Epoch Written Objects Union=0
>         Epoch DependencyMap Objects Union=0
>
>     Repository startup is from checkpoint = (fileId 2, blockId 20527)
>
>
>     Opening a transaction log file for read.
>        filename =
> /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/tranlog2.dbf
>
>     Opening a transaction log file for write.
>        filename =
> /opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/tranlog2.dbf
>
>     Starting user services with name = !#server!seaside
> --- 12/11/10 21:51:27.562 UTC :
>     Starting a Page Manager Gem process
> --- 12/11/10 21:51:27.592 UTC :    Session 1 with processId 24992 is now
> the Page Manager Gem.
>
> --- 12/11/10 21:51:28.568 UTC :
>     Starting a Reclaim Gem process for extents 0 to 0
> --- 12/11/10 21:51:28.582 UTC :
>     Starting a Admin Gem process
> --- 12/11/10 21:51:28.624 UTC :
>     Starting a SymbolCreation Gem process
>
>     Session 2 with processId 24999 is now the Page Reclaim Gem for
>     extents 0 through 0.
>
>     Session 3 with processId 25000 is now the Admin Gem.
> --- 12/11/10 21:51:28.703 UTC :    Session 4 with processId 25004 is now
> the Symbol Creation Gem.
>
>
>
Monty Williams-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Tomorrow is the final day to submit a talk for Smalltalk Solutions 2011!

Monty Williams-3
In reply to this post by Monty Williams-3
Just a quick reminder. If you have a topic that would be of interest to your fellow Smalltalkers at StS 2011, please submit your proposal ASAP!

Thanks,
Monty

---------

Smalltalk Solutions is back! The last two years have seen many new developments in Smalltalk and in the software world in general. Interest in Smalltalk is growing, and it remains the best software technology for the innovations that will shape the future.

Smalltalk Solutions is a forum where Smalltalk professionals, researchers, and enthusiasts can meet and share ideas and experiences. We are currently accepting proposals for talks involving Smalltalk technology and other areas of innovation in the software industry. We're looking forward to an excellent conference, and need your participation to maintain the high technical level of the conference!

The conference will take place in Las Vegas, Nevada, March 13 – 16, 2011.

Presentations may be in the form of

 *   Technical Presentations
 *   Experience Reports
 *   Technology Demonstrations
 *   Panel Discussions
 *   Half-day Tutorials
 *   Other interesting ideas ...

Proposals should be submitted by email to [hidden email]<mailto:[hidden email]> and should include the following information:

 *   Name
 *   Contact Information
 *   Type of Presentation
 *   Title of Presentation
 *   Brief Abstract
 *   Short Biography of the Presenter(s)
 *   Desired Length (45 minutes, 1.5 hrs, half-day)
 *   Any constraints on date/time
 *   Any other information of importance in evaluating the proposal

Submissions should be received by November 30, 2010. Note that submissions with incomplete information may be rejected - particularly if bio or abstract information is missing.

Presenters will qualify for a significantly discounted registration. This year that will be $200 US, or $160 US for STIC members.

For announcements of the conference see www.stic.st<http://www.stic.st/> and http://www.smalltalksolutions.com/.

Georg Heeg

STIC - Smalltalk Industry Council
Executive Director
Phone +49-3496-214328, Fax +49-3496-214712
Free forum by Nabble Edit this page