Memleak (in querycache?) while querying #3136
Labels
Milestone
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Date: 2012-08-02 13:44:32 +0200
From: info
To: SQL devs <>
Version: 11.11.7 (Jul2012-SP1)
CC: @njnes, @yzchang
Last updated: 2013-01-22 09:29:03 +0100
Comment 17600
Date: 2012-08-02 13:44:32 +0200
From: info
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1
Build Identifier:
After disconnecting the clientconnection the querycache doesn't seem to be emptied, as this leak doesn't show when using "SET cache=false".
We expected that the leak would only increase when using different queries, since using a query that has already been executed would've already
been cached. But even when using the same queries the leak continues to increase with each query.
There also seems to be a leak when only creating a clientconnection.
Reproducible: Always
Steps to Reproduce:
Test1: Queries=1
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=leaktest >& output_mserver5_1.txt
Terminal2: mclient -dleaktest
Terminal2: SELECT * from types LIMIT 1;
Terminal2: \q
Terminal1: \q
Test2: Queries=2
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=leaktest >& output_mserver5_1.txt
Terminal2: mclient -dleaktest
Terminal2: SELECT * from types LIMIT 1;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: \q
Terminal1: \q
Test3: Queries=3
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=leaktest >& output_mserver5_1.txt
Terminal2: mclient -dleaktest
Terminal2: SELECT * from types LIMIT 1;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: \q
Terminal1: \q
Test4: Queries=3 + "SET cache=false"
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=leaktest >& output_mserver5_1.txt
Terminal2: mclient -dleaktest
Terminal2: SET cache=false;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: SELECT * from types LIMIT 1;
Terminal2: \q
Terminal1: \q
Test5: Client connection only
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=leaktest >& output_mserver5_1.txt
Terminal2: mclient -dleaktest
Terminal2: \q
Terminal1: \q
Actual Results:
Test1: Queries=1
==24266== 40 bytes in 1 blocks are definitely lost in loss record 733 of 2,042
==24266== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==24266== by 0x58AEF65: GDKmallocmax (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24266== by 0x58AF3E9: GDKmalloc (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24266== by 0x58AF475: GDKstrdup (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24266== by 0xB1C1827: SQLinitClient (in /data/programs/MonetDB/lib/monetdb5/lib_sql.so)
==24266== by 0x4E9FFFF: ??? (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24266== by 0x4EA023E: runScenario (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24266== by 0x4EA118C: MSserveClient (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24266== by 0x6EE69C9: start_thread (pthread_create.c:300)
==24266== by 0xC1376FF: ???
Test2: Queries=2
==24292== 40 bytes in 1 blocks are definitely lost in loss record 729 of 2,040
==24292== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==24292== by 0x58AEF65: GDKmallocmax (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24292== by 0x58AF3E9: GDKmalloc (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24292== by 0x58AF475: GDKstrdup (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24292== by 0xB1C1827: SQLinitClient (in /data/programs/MonetDB/lib/monetdb5/lib_sql.so)
==24292== by 0x4E9FFFF: ??? (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24292== by 0x4EA023E: runScenario (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24292== by 0x4EA118C: MSserveClient (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24292== by 0x6EE69C9: start_thread (pthread_create.c:300)
==24292== by 0xC1376FF: ???
Test3: Queries=3
==24355== 40 bytes in 1 blocks are definitely lost in loss record 733 of 2,042
==24355== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==24355== by 0x58AEF65: GDKmallocmax (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24355== by 0x58AF3E9: GDKmalloc (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24355== by 0x58AF475: GDKstrdup (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24355== by 0xB1C1827: SQLinitClient (in /data/programs/MonetDB/lib/monetdb5/lib_sql.so)
==24355== by 0x4E9FFFF: ??? (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24355== by 0x4EA023E: runScenario (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24355== by 0x4EA118C: MSserveClient (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24355== by 0x6EE69C9: start_thread (pthread_create.c:300)
==24355== by 0xC1376FF: ???
Test4: Queries=3 + "SET cache=false"
==24374== 40 bytes in 1 blocks are definitely lost in loss record 730 of 2,036
==24374== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==24374== by 0x58AEF65: GDKmallocmax (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24374== by 0x58AF3E9: GDKmalloc (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24374== by 0x58AF475: GDKstrdup (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24374== by 0xB1C1827: SQLinitClient (in /data/programs/MonetDB/lib/monetdb5/lib_sql.so)
==24374== by 0x4E9FFFF: ??? (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24374== by 0x4EA023E: runScenario (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24374== by 0x4EA118C: MSserveClient (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24374== by 0x6EE69C9: start_thread (pthread_create.c:300)
==24374== by 0xC1376FF: ???
Test5: Client connection only
==24421== 40 bytes in 1 blocks are definitely lost in loss record 729 of 2,032
==24421== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==24421== by 0x58AEF65: GDKmallocmax (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24421== by 0x58AF3E9: GDKmalloc (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24421== by 0x58AF475: GDKstrdup (in /data/programs/MonetDB/lib/libbat.so.6.0.0)
==24421== by 0xB1C1827: SQLinitClient (in /data/programs/MonetDB/lib/monetdb5/lib_sql.so)
==24421== by 0x4E9FFFF: ??? (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24421== by 0x4EA023E: runScenario (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24421== by 0x4EA118C: MSserveClient (in /data/programs/MonetDB/lib/libmonetdb5.so.12.0.0)
==24421== by 0x6EE69C9: start_thread (pthread_create.c:300)
==24421== by 0xC1376FF: ???
Expected Results:
No memory leaks
Comment 17601
Date: 2012-08-02 13:47:32 +0200
From: info
Created attachment 137
Logfiles valgrind
Comment 17635
Date: 2012-08-22 11:26:00 +0200
From: info
Update:
monetdb --version
MonetDB Database Server Toolkit v1.0 (Jul2012-SP1)
We did a new test on empty databases through the funnel,
constantly firing the same point-query.
When we DON'T use "set cache=false":
- The queries seem to get slower over time.
- The resident memory of the mservers increases very fast to 2GB then
the increase seems to slow down (possibly because the queries are a
factor 4 slower by then)
When we use set "set cache=false":
- The queries don't get slower
- The resident memory doesn't increase.
- Switching with the funnel results in the same behavior as when NOT
using "set cache=false" as "set cache=false" works per client
connection which gets disconnected at each switch.
Comment 17636
Date: 2012-08-22 11:41:02 +0200
From: @grobian
thanks for the analysis, it looks like a clear case now
Comment 17667
Date: 2012-08-24 14:55:08 +0200
From: @sjoerdmullender
Jul2012-SP1 has been released.
Comment 17700
Date: 2012-08-24 15:25:09 +0200
From: @sjoerdmullender
After my fixes for bug #3144 I also don't see any "definitely lost" bytes anymore when replaying the tests given here. Setting or not setting cache=false doesn't matter.
I din't check slow down or growth of resident set size when doing many of these queries.
Comment 17716
Date: 2012-08-31 14:45:34 +0200
From: @grobian
(In reply to comment 5)
@op: is the problem still visible to you after these fixes?
Comment 17717
Date: 2012-08-31 14:53:41 +0200
From: info
(In reply to comment 6)
Yes, the slowdown and growth are still visible. For now we have made the following change to sql_mvc.c:
Function mvc_create:
m->cache = 1;
to
m->cache = 0;
Function mvc_create:
if (m->cache != 1)
stack_set_number(m, "cache", 1);
m->cache = 1;
to
if (m->cache != 0)
stack_set_number(m, "cache", 0);
m->cache = 0;
This was done to have 'set cache=false' as the default. Not sure if these changes are completely correct, but it does stop the growth and slowdown for us.
Comment 18045
Date: 2012-11-27 12:53:29 +0100
From: @njnes
maybe we should make the size of the cache tunable.
Comment 18106
Date: 2012-11-27 15:14:05 +0100
From: @yzchang
Not possible to add test for this bug
Comment 18218
Date: 2012-11-28 21:02:38 +0100
From: @njnes
leaks are fixed and where unrelated to the query cache.
The sql env variable 'cache' can now be set to the maximum allowed cached queries.
Default is 20000.
Comment 18358
Date: 2013-01-22 09:29:03 +0100
From: @sjoerdmullender
Oct2012-SP3 has been released.
The text was updated successfully, but these errors were encountered: