Hi Thomas,
Ok!
Regards,
Fred
2015-03-05 4:53 GMT-03:00 Thomas Mueller :
> Hi,
>
> I have a new patch for the LIRS cache:
>
> Index: src/main/org/h2/mvstore/cache/CacheLongKeyLIRS.java
> ===
> --- src/main/org/h2/mvstore/cache/Cach
Hi,
I have a new patch for the LIRS cache:
Index: src/main/org/h2/mvstore/cache/CacheLongKeyLIRS.java
===
--- src/main/org/h2/mvstore/cache/CacheLongKeyLIRS.java (revision 6051)
+++ src/main/org/h2/mvstore/cache/CacheLongKeyLIRS.java
Hi,
Thanks a lot for the test cases and the patch! I'm still trying to
understand the patch, and I am trying to find a simpler way to fix the
problem.
Regards,
Thomas
On Sunday, March 1, 2015, Fred&Dani&Pandora&Aquiles
wrote:
> Hi Thomas,
>
> I attached a patch that reproduces the problem and
Hi Thomas,
I attached a patch that reproduces the problem and I reviewed my previous
patch that try to reduce the memory below of the limit. It passed in the
regression tests too.
Regards,
Fred
2015-02-27 16:42 GMT-03:00 Thomas Mueller :
> Hi,
>
> OK, that sounds like a bug. Do you have a si
Hi,
No, I saw this when I was evaluating the cache implementation trying to
solve the size problem, but I'll work in a test case.
Regards,
Fred
2015-02-27 16:42 GMT-03:00 Thomas Mueller :
> Hi,
>
> OK, that sounds like a bug. Do you have a simple test case for this (a
> patch to TestCacheLong
Hi,
OK, that sounds like a bug. Do you have a simple test case for this (a
patch to TestCacheLongKeyLIRS or TestCacheLIRS?
Regards,
Thomas
On Fri, Feb 20, 2015 at 12:39 PM, Fred&Dani&Pandora&Aquiles <
zepf...@gmail.com> wrote:
> Hi,
>
> I expressed myself incorrectly in the previous post. The c
Hi,
Thanks a lot! Yes, this is also what I found. I think there is another
problem: with larger databases, this cache gets less and less efficient.
I'm working on this now.
Regards,
Thomas
On Fri, Feb 20, 2015 at 11:19 AM, Fred&Dani&Pandora&Aquiles <
zepf...@gmail.com >
wrote:
> Hi Thomas,
>
Hi,
I expressed myself incorrectly in the previous post. The cold stack do not
becomes empty, the size of the stack is reduced to one element, the newCold
item. Thus, the memory used is not reduced, even with elements in the hot
stack that could be moved to the cold stack.
Regards,
Fred
2015-02
Hi again,
I don't know if would be necessary to create another thread, but during my
analysis of LIRS implementation I dealt with some cases where the cold
stack becomes empty and the memory limit continued to not met. What you
think of the attached patch?
Regards,
Fred
2015-02-19 16:31 GMT-02:
Hi Thomas,
I think I found the problem. When the PageChildren is added to the cache,
its size is configured as 1 byte and the cache grows because the informed
memory do not reflects the approximated real size. In my tests, the size of
the cacheChunkRef decreased from 87MB to ~5MB.
Regards,
Fred
Hi,
Thanks a lot for the test case! I can now reproduce it, and I'm working on
a fix.
Regards,
Thomas
On Fri, Feb 13, 2015 at 2:31 AM, Trask Stalnaker
wrote:
> The code below dumps a heap with ~86mb cacheChunkRef. If you bump
> OUTER_LOOP_COUNT to 1,000,000, it dumps a heap with ~469mb cacheC
The code below dumps a heap with ~86mb cacheChunkRef. If you bump
OUTER_LOOP_COUNT to 1,000,000, it dumps a heap with ~469mb cacheChunkRef.
public class MVStoreTest {
private static final int OUTER_LOOP_COUNT = 10;
public static void main(String[] args) throws Exception {
C
Hi,
That means the LIRS cache keeps too many non-resident cold entries. I
wonder how to best reproduce this problem... Do you have a simple test case
(a description what you do would be enough in this case)?
Regards,
Thomas
On Thu, Feb 12, 2015 at 3:17 AM, Trask Stalnaker
wrote:
> Hi,
>
> I wa
Hi,
I was looking over a heap dump and was surprised by MVStore.cacheChunkRef
consuming 29mb memory.
MVStore.cache is consuming 14mb which makes sense given the 16mb default
cache limit.
Eclipse MemoryAnalyzer OQL shows 100,000+
org.h2.mvstore.cache.CacheLongKeyLIRS$Entry objects with memory
14 matches
Mail list logo
