HEAPalloc: Insufficient space for HEAP

[Thilo Bohr]

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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Stefan Manegold]

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_aware/)
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_aware/
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@... 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@...
> https://lists.sourceforge.net/lists/listinfo/monetdb-users
>

--
| Dr. Stefan Manegold | mailto:Stefan.Manegold@... |
| CWI,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: [phone]       |
| The Netherlands     | Fax : [phone]       |

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Thilo Bohr]

tbohr@... 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

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Thilo Bohr]

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_aware/)
> 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_aware/

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@... 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@...
>> https://lists.sourceforge.net/lists/listinfo/monetdb-users
>>
>

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Stefan Manegold]

On Tue, Nov 10, 2009 at 11:00:59AM +0100, tbohr@... 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,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: [phone]       |
| The Netherlands     | Fax : [phone]       |

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Sam Mason]

On Tue, Nov 10, 2009 at 10:45:10AM +0100, tbohr@... 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/

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users

[Thilo Bohr]

Sam Mason schrieb:

> On Tue, Nov 10, 2009 at 10:45:10AM +0100, tbohr@... 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.


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/monetdb-users