You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Vladimir Olenin <VO...@cihi.ca> on 2006/08/25 00:51:36 UTC
HELP - very weird behaviour
Hi,
I'm using the following configuration:
----------------------------
jcs.default=DC
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
es
jcs.default.cacheattributes.MaxObjects=1000
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
.lru.LRUMemoryCache
# AVAILABLE AUXILIARY CACHES
jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
actory
jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
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
RE: HELP - very weird behaviour - solved
Posted by Vladimir Olenin <VO...@cihi.ca>.
Ok. This has to be put somewhere Wiki. The problem was in a missing
logging configuration. It seems to be the SLF4J bug, since 'standard'
commons-logging.jar implementation doesn't give this problem.
For the record, below is the configuration, which caused the problem:
- SLF4J implementation of Commons Logging:
- jcl104-over-slf4j.jar
- slf4j-log4j12.jar
- Log4J library
- log4j-1.2.8.jar
- JCS library:
- jcs-1.2.7.9.jar
- log4j.properties file is NOT present
This results in the following two (standard) warning lines from log4j
output to the console at application startup:
log4j:WARN No appenders could be found for logger
(org.apache.jcs.engine.control.CompositeCacheManager).
log4j:WARN Please initialize the log4j system properly.
If log4j is configured properly OR commons-logging.jar file is used as
CommonsLogging implementation, then everything works as expected.
Thanks everyone for help!
-----Original Message-----
From: Vladimir Olenin [mailto:VOlenin@cihi.ca]
Sent: Friday, August 25, 2006 10:39 AM
To: JCS Users List
Subject: RE: HELP - very weird behaviour
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 <VO...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: HELP - very weird behaviour
Posted by Vladimir Olenin <VO...@cihi.ca>.
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 <VO...@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
Re: HELP - very weird behaviour
Posted by Hanson Char <ha...@gmail.com>.
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 <VO...@cihi.ca> wrote:
> Hi,
>
> I'm using the following configuration:
>
> ----------------------------
> jcs.default=DC
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
> es
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
> .lru.LRUMemoryCache
>
>
> # AVAILABLE AUXILIARY CACHES
> jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
> actory
> jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
> 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