jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Olenin" <VOle...@cihi.ca>
Subject RE: HELP - very weird behaviour
Date Fri, 25 Aug 2006 14:38:54 GMT
Thanks. I've checked you suggestions, just to be on the safe side, but
GC is definitely not an issue. ALL serialized structures I put into
cache take at most 5M. The GC output shows only Young generation
collections, which are fast (< 0.004). The JVM params used are:
-verbose:gc -server -Xms64M -Xmx64M  -Xloggc:gc.log -XX:GCTimeRatio=19

0.000: [GC 5824K->1725K(64832K), 0.0164626 secs]
0.449: [GC 7549K->2593K(64832K), 0.0203206 secs]
0.593: [GC 8417K->2362K(64832K), 0.0067281 secs]
0.795: [GC 8186K->2620K(64832K), 0.0069210 secs]
0.987: [GC 8444K->2820K(64832K), 0.0069212 secs]
1.221: [GC 8644K->3158K(64832K), 0.0060625 secs]
1.356: [GC 8982K->3434K(64832K), 0.0086940 secs]
1.645: [GC 9258K->3786K(64832K), 0.0065196 secs]

The gc output & behaviour does NOT seem to differ depending on the
'MaxObjects' parameter...

Any other insights?.....

Vlad

-----Original Message-----
From: Hanson Char [mailto:hanson.char@gmail.com] 
Sent: Thursday, August 24, 2006 7:38 PM
To: JCS Users List
Subject: Re: HELP - very weird behaviour

Can GC, heap memory min/max sizes, and the GC throughput target be some
factors ?  What JVM are you running on ?  If Java 5, you can try some of
these JVM parameters:

-server for server mode
-verbose:gc to find out more about what the GC is doing
-XX:+UseParallelGC for concurrent GC
-XX:GCTimeRatio=19 for the target throughput rate (default is 99)
-Xms512m -Xmx512m  for the min/max heap memory size

For example:

java -server -verbose:gc -XX:+UseParallelGC -XX:GCTimeRatio=19 -Xms512m
-Xmx512m Main

My 2 cents.

Hanson

On 8/24/06, Vladimir Olenin <VOlenin@cihi.ca> wrote:
> Hi,
>
> I'm using the following configuration:
>
> ----------------------------
> jcs.default=DC
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttrib
> ut
> es
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memo
> ry
> .lru.LRUMemoryCache
>
>
> # AVAILABLE AUXILIARY CACHES
> jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCach
> eF
> actory
> jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Inde
> xe
> dDiskCacheAttributes
> jcs.auxiliary.DC.attributes.DiskPath=./temp
> jcs.auxiliary.DC.attributes.maxKeySize=100000
> jcs.auxiliary.DC.attributes.MaxPurgatorySize=100000
> ------------------------
>
> The weird thing is that the entries retrieval performance degrades 
> when 'jcs.default.cacheattributes.MaxObjects' grows. I assumed it 
> should be the other way around. When I set this value to '10000' and 
> put not more than '10000' entries in cache, the jcs.get(key) start to
CRAWL!!!
> (returns within 2-3 seconds) with CPU consumption at 100%. The 'data'
> and 'key' files are empty, which seems to prove that all entries are 
> contained in memory and nothing has been swapped to HD.
>
> When that setting is at '10', 'data' and 'key' files are growing to 
> several megs (with my data), which seem to prove that almost all 
> entries are swaped to HD, while jcs.get() call returns within serveral

> milliseconds.
>
> What am I doing wrong?...
>
> Thanks.
>
> Vlad
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message