[MonetDB-users] HEAPalloc: Insufficient space for HEAP
Hi, when I run the following query (complete testcase given), the server throws an exception !MALException:bbp.project:Can not create object !ERROR: HEAPalloc: Insufficient space for HEAP of 91226112 bytes. The result should be 11390625 (15^6) rows. The corresponding count query succesfully delivers this value. The amount of used memory of the mserver5.exe process is about 1.2GB at the time of failure. The testcase is: create table d (id integer, ordinal integer, value varchar(50)); insert into d (id, ordinal, value) values (1,1,'a'), (2,2,'b'), (3,3,'c'), (4,4,'d'), (5,5,'e'), (6,6,'f'), (7,7,'g'), (8,8,'h'), (9,9,'i'), (10,10,'j'), (11,11,'k'), (12,12,'l'), (13,13,'m'), (14,14,'n'), (15,15,'o'); create table M_189 (d1 integer, d11 integer, d19 integer, d4 integer, d6 integer, d8 integer, value double); SELECT G.M_ID, G.VALUE, G.d1, G.d11, G.d19, G.d4, G.d6, G.d8 FROM (SELECT DISTINCT 189 AS M_ID, 1 AS M_ORDINAL, M_189.VALUE AS VALUE, D1.ID AS d1, D11.ID AS d11, D19.ID AS d19, D4.ID AS d4, D6.ID AS d6, D8.ID AS d8 FROM D D11 CROSS JOIN D D1 CROSS JOIN D D4 CROSS JOIN D D6 CROSS JOIN D D8 CROSS JOIN D D19 LEFT OUTER JOIN M_189 ON M_189.d1=D1.ID AND M_189.d11=D11.ID AND M_189.d19=D19.ID AND M_189.d4=D4.ID AND M_189.d6=D6.ID AND M_189.d8=D8.ID ) G JOIN D D11 ON D11.ID=G.d11 JOIN D D6 ON D6.ID=G.d6 JOIN D D8 ON D8.ID=G.d8 JOIN D D19 ON D19.ID=G.d19 JOIN D D1 ON D1.ID=G.d1 JOIN D D4 ON D4.ID=G.d4 ORDER BY G.M_ORDINAL, D11.ORDINAL, D6.ORDINAL, D8.ORDINAL, D19.ORDINAL, D1.ORDINAL, D4.ORDINAL; Kind regards, TB
Hi TB, given that you mention mserver5*.exe*, I assume you are running MonetDB on Windows, right? Is your system (and your MonetDB) 32-bit or 64-bit? If 32-bit, you (resp. MonetDB) is most probably running out of address space; 32-bit Windows usually allow to address only 2 GB (max. 3 GB; cf. http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/enable_lrg_ad_awa...) of the theoretically possible 4 GB; moreover, it is know to suffer from address space fragmentation. In you case, with mserver5.exe already occupying 1.2 GB, there seems to be no single *consecutive* address range freely avaiable anymore for allocating an other ~91 MB. You might want to check http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/enable_lrg_ad_awa... to make your 32-bit Windows system indeed allow addressing up to 3 GB, or need to consider mgrating to a 64-bit system, in particular since your query features Cartesian products, and hence triggers large "exploding" intermediate results. Or would it be possible to rephrase your query without Cartesian products? Stefan ps: Out of curiosity: Wich version of MonetDB are you running, and does the server continue running after issuing the reported error? On Tue, Nov 10, 2009 at 10:23:25AM +0100, tbohr@quantentunnel.de wrote:
Hi,
when I run the following query (complete testcase given), the server throws an exception
!MALException:bbp.project:Can not create object !ERROR: HEAPalloc: Insufficient space for HEAP of 91226112 bytes.
The result should be 11390625 (15^6) rows. The corresponding count query succesfully delivers this value.
The amount of used memory of the mserver5.exe process is about 1.2GB at the time of failure.
The testcase is:
create table d (id integer, ordinal integer, value varchar(50)); insert into d (id, ordinal, value) values (1,1,'a'), (2,2,'b'), (3,3,'c'), (4,4,'d'), (5,5,'e'), (6,6,'f'), (7,7,'g'), (8,8,'h'), (9,9,'i'), (10,10,'j'), (11,11,'k'), (12,12,'l'), (13,13,'m'), (14,14,'n'), (15,15,'o'); create table M_189 (d1 integer, d11 integer, d19 integer, d4 integer, d6 integer, d8 integer, value double);
SELECT G.M_ID, G.VALUE, G.d1, G.d11, G.d19, G.d4, G.d6, G.d8 FROM (SELECT DISTINCT 189 AS M_ID, 1 AS M_ORDINAL, M_189.VALUE AS VALUE, D1.ID AS d1, D11.ID AS d11, D19.ID AS d19, D4.ID AS d4, D6.ID AS d6, D8.ID AS d8 FROM D D11 CROSS JOIN D D1 CROSS JOIN D D4 CROSS JOIN D D6 CROSS JOIN D D8 CROSS JOIN D D19 LEFT OUTER JOIN M_189 ON M_189.d1=D1.ID AND M_189.d11=D11.ID AND M_189.d19=D19.ID AND M_189.d4=D4.ID AND M_189.d6=D6.ID AND M_189.d8=D8.ID ) G JOIN D D11 ON D11.ID=G.d11 JOIN D D6 ON D6.ID=G.d6 JOIN D D8 ON D8.ID=G.d8 JOIN D D19 ON D19.ID=G.d19 JOIN D D1 ON D1.ID=G.d1 JOIN D D4 ON D4.ID=G.d4 ORDER BY G.M_ORDINAL, D11.ORDINAL, D6.ORDINAL, D8.ORDINAL, D19.ORDINAL, D1.ORDINAL, D4.ORDINAL;
Kind regards, TB
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
Stefan Manegold schrieb:
Hi TB,
given that you mention mserver5*.exe*, I assume you are running MonetDB on Windows, right?
Is your system (and your MonetDB) 32-bit or 64-bit?
If 32-bit, you (resp. MonetDB) is most probably running out of address space; 32-bit Windows usually allow to address only 2 GB (max. 3 GB; cf. http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/enable_lrg_ad_awa...) of the theoretically possible 4 GB; moreover, it is know to suffer from address space fragmentation. In you case, with mserver5.exe already occupying 1.2 GB, there seems to be no single *consecutive* address range freely avaiable anymore for allocating an other ~91 MB.
You might want to check http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/enable_lrg_ad_awa...
Hi Stefan, I will give this a try, thanks!
to make your 32-bit Windows system indeed allow addressing up to 3 GB, or need to consider mgrating to a 64-bit system, in particular since your query features Cartesian products, and hence triggers large "exploding" intermediate results. Or would it be possible to rephrase your query without Cartesian products?
Unfortunately not - on the other hand this is a kind of worst-case scenario query. The good news is (I already posted that as a reply to my posting) that with dropping the DISTINCT modifier, the query is executed - and that pretty fast.
Stefan
ps: Out of curiosity: Wich version of MonetDB are you running, and does the server continue running after issuing the reported error?
The server still runs, in contrast to the situation described in my posting from yesterday (MALException:algebra.join,HEAPextend: failed to extend). The other information can be found in this posting as well.
On Tue, Nov 10, 2009 at 10:23:25AM +0100, tbohr@quantentunnel.de wrote:
Hi,
when I run the following query (complete testcase given), the server throws an exception
!MALException:bbp.project:Can not create object !ERROR: HEAPalloc: Insufficient space for HEAP of 91226112 bytes.
The result should be 11390625 (15^6) rows. The corresponding count query succesfully delivers this value.
The amount of used memory of the mserver5.exe process is about 1.2GB at the time of failure.
The testcase is:
create table d (id integer, ordinal integer, value varchar(50)); insert into d (id, ordinal, value) values (1,1,'a'), (2,2,'b'), (3,3,'c'), (4,4,'d'), (5,5,'e'), (6,6,'f'), (7,7,'g'), (8,8,'h'), (9,9,'i'), (10,10,'j'), (11,11,'k'), (12,12,'l'), (13,13,'m'), (14,14,'n'), (15,15,'o'); create table M_189 (d1 integer, d11 integer, d19 integer, d4 integer, d6 integer, d8 integer, value double);
SELECT G.M_ID, G.VALUE, G.d1, G.d11, G.d19, G.d4, G.d6, G.d8 FROM (SELECT DISTINCT 189 AS M_ID, 1 AS M_ORDINAL, M_189.VALUE AS VALUE, D1.ID AS d1, D11.ID AS d11, D19.ID AS d19, D4.ID AS d4, D6.ID AS d6, D8.ID AS d8 FROM D D11 CROSS JOIN D D1 CROSS JOIN D D4 CROSS JOIN D D6 CROSS JOIN D D8 CROSS JOIN D D19 LEFT OUTER JOIN M_189 ON M_189.d1=D1.ID AND M_189.d11=D11.ID AND M_189.d19=D19.ID AND M_189.d4=D4.ID AND M_189.d6=D6.ID AND M_189.d8=D8.ID ) G JOIN D D11 ON D11.ID=G.d11 JOIN D D6 ON D6.ID=G.d6 JOIN D D8 ON D8.ID=G.d8 JOIN D D19 ON D19.ID=G.d19 JOIN D D1 ON D1.ID=G.d1 JOIN D D4 ON D4.ID=G.d4 ORDER BY G.M_ORDINAL, D11.ORDINAL, D6.ORDINAL, D8.ORDINAL, D19.ORDINAL, D1.ORDINAL, D4.ORDINAL;
Kind regards, TB
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Tue, Nov 10, 2009 at 11:00:59AM +0100, tbohr@quantentunnel.de wrote: [...]
The server still runs, in contrast to the situation described in my posting from yesterday (MALException:algebra.join,HEAPextend: failed to extend). The other information can be found in this posting as well.
We are working on making MonetDB more robust against allocation failure due to running out of address space with larger (intermediate) data volumes on 32-bit systems, i.e., we try to keep the server alive in such cases (some improvements will be available in the upcoming Nov2009 feature release; more will come later). However, we cannot (easily) lower the address space requirements of MonetDB. They stem from MonetDB's operator-at-a time bulk-processing execution paradigm that MonetDB owns major parts of its performance to. Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
tbohr@quantentunnel.de schrieb:
Hi,
when I run the following query (complete testcase given), the server throws an exception
!MALException:bbp.project:Can not create object !ERROR: HEAPalloc: Insufficient space for HEAP of 91226112 bytes.
The result should be 11390625 (15^6) rows. The corresponding count query succesfully delivers this value.
The amount of used memory of the mserver5.exe process is about 1.2GB at the time of failure.
The testcase is:
create table d (id integer, ordinal integer, value varchar(50)); insert into d (id, ordinal, value) values (1,1,'a'), (2,2,'b'), (3,3,'c'), (4,4,'d'), (5,5,'e'), (6,6,'f'), (7,7,'g'), (8,8,'h'), (9,9,'i'), (10,10,'j'), (11,11,'k'), (12,12,'l'), (13,13,'m'), (14,14,'n'), (15,15,'o'); create table M_189 (d1 integer, d11 integer, d19 integer, d4 integer, d6 integer, d8 integer, value double);
SELECT G.M_ID, G.VALUE, G.d1, G.d11, G.d19, G.d4, G.d6, G.d8 FROM (SELECT DISTINCT 189 AS M_ID, 1 AS M_ORDINAL, M_189.VALUE AS VALUE,
Ok, removing the superfluous DISTINCT helps, but still I am a little concerned that the server does not use more of the available memory (3.5GB on my machine) and claims that an additional chunk of 91MB can not be allocated (this is how I interpret the above error message).
D1.ID AS d1, D11.ID AS d11, D19.ID AS d19, D4.ID AS d4, D6.ID AS d6, D8.ID AS d8 FROM D D11 CROSS JOIN D D1 CROSS JOIN D D4 CROSS JOIN D D6 CROSS JOIN D D8 CROSS JOIN D D19 LEFT OUTER JOIN M_189 ON M_189.d1=D1.ID AND M_189.d11=D11.ID AND M_189.d19=D19.ID AND M_189.d4=D4.ID AND M_189.d6=D6.ID AND M_189.d8=D8.ID ) G JOIN D D11 ON D11.ID=G.d11 JOIN D D6 ON D6.ID=G.d6 JOIN D D8 ON D8.ID=G.d8 JOIN D D19 ON D19.ID=G.d19 JOIN D D1 ON D1.ID=G.d1 JOIN D D4 ON D4.ID=G.d4 ORDER BY G.M_ORDINAL, D11.ORDINAL, D6.ORDINAL, D8.ORDINAL, D19.ORDINAL, D1.ORDINAL, D4.ORDINAL;
Kind regards, TB
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
On Tue, Nov 10, 2009 at 10:45:10AM +0100, tbohr@quantentunnel.de wrote:
I am a little concerned that the server does not use more of the available memory (3.5GB on my machine) and claims that an additional chunk of 91MB can not be allocated (this is how I interpret the above error message).
Physical RAM and a process's "address space" bear very little relation to each other, the fact that it can only usefully use 1.2GB of its *address space* is an artifact of the design of windows. Reading around virtual memory and address spaces may clear things up, the basic intuition is that if you've got a 32bit process it doesn't matter how much memory you have it will have very strict limits on the amount of memory it can address (access/use). 64bit processes (hence a 64bit address space) effectively remove this limitation and allows you to address all memory you could sensibly put into a single box. Most recent machines can use a 64bit address space, maybe you could try a live-cd version of Linux? -- Sam http://samason.me.uk/
Sam Mason schrieb:
On Tue, Nov 10, 2009 at 10:45:10AM +0100, tbohr@quantentunnel.de wrote:
I am a little concerned that the server does not use more of the available memory (3.5GB on my machine) and claims that an additional chunk of 91MB can not be allocated (this is how I interpret the above error message).
Physical RAM and a process's "address space" bear very little relation to each other, the fact that it can only usefully use 1.2GB of its *address space* is an artifact of the design of windows. Reading around virtual memory and address spaces may clear things up, the basic intuition is that if you've got a 32bit process it doesn't matter how much memory you have it will have very strict limits on the amount of memory it can address (access/use). 64bit processes (hence a 64bit address space) effectively remove this limitation and allows you to address all memory you could sensibly put into a single box.
Most recent machines can use a 64bit address space, maybe you could try a live-cd version of Linux?
Unfortunately this is not an option, but thanks for your explanations. Kind regards, TB.
participants (3)
-
Sam Mason -
Stefan Manegold -
tbohr＠quantentunnel.de