Martin Kersten wrote:
> For large table loads (relative to the swap size) it is advisable to
> load in multiple steps.
> First load the data into the tables without (foreign) key checks.
> After this step ALTER the tables to respect the (foreign) keys.
I don't know if it was the swap space or th
Hi Peter,
Peter Boncz wrote:
> Like Martin indicated, MonetDB runs out of memory here, when trying to obtain
> a contiguous area of 14GB.
But is a contiguous area of 14GB required for this? That is much memory!
> The error messages show that MonetDB is pulling all the stops to try to get
> this
ts machine (naughty naughty)
For these large sizes, and the way MonetDB manages mamory, you need a 64-bits
OS.
Peter
> Message: 4
> Date: Sun, 23 Nov 2008 02:04:09 +0100
> From: Stefan de Konink <[EMAIL PROTECTED]>
> Subject: [Monetdb-developers] Could not create hash table fo
Martin Kersten wrote:
> For large table loads (relative to the swap size) it is advisable to
> load in multiple steps.
> First load the data into the tables without (foreign) key checks.
> After this step ALTER the tables to respect the (foreign) keys.
Sadly the 49GB table will also not insert wi
Stefan de Konink wrote:
> On Sun, 23 Nov 2008, Martin Kersten wrote:
>
>
>> Stefan de Konink wrote:
>>
>>> #BBPTRIM_ENTER: memsize=180224,vmsize=14397997056
>>> #BBPTRIM: memtarget=0 vmtarget=0
>>> #BBPTRIM_EXIT: memsize=20365312,vmsize=14397997056
>>> #BBPTRIM_ENTER: memsize=2496368440,vms
On Sun, 23 Nov 2008, Stefan Manegold wrote:
> From the trace above, I comclude that MonetDB is unable to allocate a 14GB
> chunk --- first (obvious) questions to ask and answer:
> Is your CoreDuo (or Core2Duo?) a 64-bit CPU?
64bit kernel/userland. I don't think it is actually both, it is one of
t
On Sun, 23 Nov 2008, Martin Kersten wrote:
> Stefan de Konink wrote:
> > #BBPTRIM_ENTER: memsize=180224,vmsize=14397997056
> > #BBPTRIM: memtarget=0 vmtarget=0
> > #BBPTRIM_EXIT: memsize=20365312,vmsize=14397997056
> > #BBPTRIM_ENTER: memsize=2496368440,vmsize=16874000184
> > #BBPTRIM: memtarget=7
On Sun, 23 Nov 2008, Martin Kersten wrote:
> The system is trying to malloc space for (in this case) a hash table,
> but that instruction fails. Then it attempts to free up memory by
> swapping out tables.
> Given the fact that after this sweep it still fails, indicates that
> your swap memory ha
On Sun, Nov 23, 2008 at 02:04:09AM +0100, Stefan de Konink wrote:
> #GDKmalloc(14777222432) fail => BBPtrim(enter)
> usage[mem=14840896,vm=27527806976]
> #BBPTRIM_ENTER: memsize=14840896,vmsize=27527806976
> #BBPTRIM: memtarget=4611686018427387904 vmtarget=0
> #BBPTRIM_EXIT: memsize=19120128,vms
Stefan de Konink wrote:
> #BBPTRIM_ENTER: memsize=180224,vmsize=14397997056
> #BBPTRIM: memtarget=0 vmtarget=0
> #BBPTRIM_EXIT: memsize=20365312,vmsize=14397997056
> #BBPTRIM_ENTER: memsize=2496368440,vmsize=16874000184
> #BBPTRIM: memtarget=778092856 vmtarget=0
> #BBPTRIM_EXIT: memsize=20365312,vm
Dear Stefan,
Let's explain as far as possible.
Stefan de Konink wrote:
> #GDKmalloc(14777222432) fail => BBPtrim(enter)
> usage[mem=14840896,vm=27527806976]
> #BBPTRIM_ENTER: memsize=14840896,vmsize=27527806976
> #BBPTRIM: memtarget=4611686018427387904 vmtarget=0
> #BBPTRIM_EXIT: memsize=191201
#BBPTRIM_ENTER: memsize=180224,vmsize=14397997056
#BBPTRIM: memtarget=0 vmtarget=0
#BBPTRIM_EXIT: memsize=20365312,vmsize=14397997056
#BBPTRIM_ENTER: memsize=2496368440,vmsize=16874000184
#BBPTRIM: memtarget=778092856 vmtarget=0
#BBPTRIM_EXIT: memsize=20365312,vmsize=10150287928
Killed
This one al
#GDKmalloc(14777222432) fail => BBPtrim(enter)
usage[mem=14840896,vm=27527806976]
#BBPTRIM_ENTER: memsize=14840896,vmsize=27527806976
#BBPTRIM: memtarget=4611686018427387904 vmtarget=0
#BBPTRIM_EXIT: memsize=19120128,vmsize=27527806976
#GDKmalloc(14777222432) fail => BBPtrim(ready)
usage[mem=11
13 matches
Mail list logo
