[infinispan-issues] [JBoss JIRA] Commented: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0
Galder Zamarreño (JIRA)
jira-events at lists.jboss.org
Tue Oct 5 07:07:39 EDT 2010
[ https://jira.jboss.org/browse/ISPN-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555218#action_12555218 ]
Galder Zamarreño commented on ISPN-663:
---------------------------------------
Wrt: lost entries if replication/distribution disabled
Yes, with passivation, either data is in memory or in cache store, so without clustering data could be lost.
Re 1) Only Vladimir/Manik can confirm what the status of DEFAULT is. I'm not sure though how you can introduce a BACKGROUND policy that's intelligent enough to know that there's a passivation backlog. I think what you mean is that the eviction manager or the containers see how many evictions are waiting and send them to a different thread so that it can evict and passivate. However, for this particular case, the issue can be solved by using an asynchronous cache store (http://community.jboss.org/docs/DOC-14629) whereby the actual cache store time is passed to a different thread. This would emulate the previous way eviction worked where passivation happened in a different thread.
Re 2) Hmmm, when would commit() not get called? If commit is not called, the operation is not to be written, so the unfinished JDBM write did not complete, so it's fine for it get lost. I'm not sure I understand the API change you suggest.
> Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0
> --------------------------------------------------------------------------------
>
> Key: ISPN-663
> URL: https://jira.jboss.org/browse/ISPN-663
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction, Loaders and Stores
> Affects Versions: 4.1.0.Final
> Environment: Win32 JRE 1.6.0_21
> Reporter: Paul Nardone
> Assignee: Trustin Lee
> Fix For: 4.2.0.BETA1, 4.2.0.Final
>
> Attachments: InfinispanPassivationTest.java
>
>
> Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL.
> The degredation in performance is so signficant to make it impossible to use
> The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity.
> The attached test inserts 1000 values into two caches
> Both caches use a JdbmCacheStore and LRU
> PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10
> PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000
> 4.1.0.FINAL
> PASSIVATIONLRU10 Time Taken : 51704
> PASSIVATIONLRU1000 Time Taken : 4484
> 4.0.0.FINAL
> PASSIVATIONLRU10 Time Taken : 281
> PASSIVATIONLRU1000 Time Taken : 141
> 4.2.0.ALPHA2
> PASSIVATIONLRU10 Time Taken : 51047
> PASSIVATIONLRU1000 Time Taken : 5156
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list