Monetdb bulk copy crash
Hi, I am using the latest MonetDB (Oct 2012 release) and creating an RDF database of 1.33 billion triples as follows: $ monetdbd start /path/to/dbfarm $ monetdb create rdf1b $ monetdb release rdf1b $ monetdb start rdf1b _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Hi, Monetdb 11.13.3 (Oct 2012) keeps crashing on bulk copy/load of an RDF dataset (in integer format) of 1.33 billion triples. /var/log/syslog shows mserver5 killed by the kernel "oom_signal (Out Of Memory)". Sometimes "mclient" it just aborts the operation by saying that "probably not enough disk space", whereas there is ample disk space left on the drive ($120+ GB). I loaded another RDF dataset of 800 million triples in the same integer ID format and it got loaded correctly with similar commands, just tables names and vertical partitions were different. Additionally, I had loaded the same 1.33 billion dataset on the older version of MonetDB (July 2012 SP2) (11.9.7), and it gets loaded correctly through that. So I wonder what changed from 11.9.7 to 11.13.3 that the bulk loader started crashing on one dataset of 1.33 billion triples, but works fine for 800 million triples. Can I use 11.9.7 to load data and 11.13.3 to query it? (I need to run some experiments which can't wait longer and I would prefer using the latest release for query evaluation.) Medha -- Some more details about what I am doing -- -------------------------------------------------------- Using the latest MonetDB (Oct 2012 release) and creating an RDF database of 1.33 billion triples as follows: $ monetdbd start /path/to/dbfarm $ monetdb create rdf1b $ monetdb release rdf1b $ monetdb start rdf1b $ zcat /path/to/colonsep-id-file.gz > /path/to/lubm1b.fifo & ------------------ Contents of /path/to/colosep-id-file.gz look like -------- 1:2:3 5:6:7 5:6:9 -------- etc. ------------------ $ mclient -d rdf1b -l sql < /path/to/bulkcopy-sql-cmds The bulk copy SQL commands are create table lubm1b(sub int, pred int, obj int); copy into lubm1b from '/path/to/lubm1b.fifo' using delimiters ':','\n'; create table lubm1b_p1(sub int, obj int); create table lubm1b_p2(sub int, obj int); create table lubm1b_p3(sub int, obj int); create table lubm1b_p4(sub int, obj int); create table lubm1b_p5(sub int, obj int); create table lubm1b_p6(sub int, obj int); create table lubm1b_p7(sub int, obj int); create table lubm1b_p8(sub int, obj int); create table lubm1b_p9(sub int, obj int); create table lubm1b_p10(sub int, obj int); create table lubm1b_p11(sub int, obj int); create table lubm1b_p12(sub int, obj int); create table lubm1b_p13(sub int, obj int); create table lubm1b_p14(sub int, obj int); create table lubm1b_p15(sub int, obj int); create table lubm1b_p16(sub int, obj int); create table lubm1b_p17(sub int, obj int); create table lubm1b_p18(sub int, obj int); insert into lubm1b_p1 select sub, obj from lubm1b where pred=1 order by sub, obj; insert into lubm1b_p2 select sub, obj from lubm1b where pred=2 order by sub, obj; insert into lubm1b_p3 select sub, obj from lubm1b where pred=3 order by sub, obj; insert into lubm1b_p4 select sub, obj from lubm1b where pred=4 order by sub, obj; insert into lubm1b_p5 select sub, obj from lubm1b where pred=5 order by sub, obj; insert into lubm1b_p6 select sub, obj from lubm1b where pred=6 order by sub, obj; insert into lubm1b_p7 select sub, obj from lubm1b where pred=7 order by sub, obj; insert into lubm1b_p8 select sub, obj from lubm1b where pred=8 order by sub, obj; insert into lubm1b_p9 select sub, obj from lubm1b where pred=9 order by sub, obj; insert into lubm1b_p10 select sub, obj from lubm1b where pred=10 order by sub, obj; insert into lubm1b_p11 select sub, obj from lubm1b where pred=11 order by sub, obj; insert into lubm1b_p12 select sub, obj from lubm1b where pred=12 order by sub, obj; insert into lubm1b_p13 select sub, obj from lubm1b where pred=13 order by sub, obj; insert into lubm1b_p14 select sub, obj from lubm1b where pred=14 order by sub, obj; insert into lubm1b_p15 select sub, obj from lubm1b where pred=15 order by sub, obj; insert into lubm1b_p16 select sub, obj from lubm1b where pred=16 order by sub, obj; insert into lubm1b_p17 select sub, obj from lubm1b where pred=17 order by sub, obj; insert into lubm1b_p18 select sub, obj from lubm1b where pred=18 order by sub, obj; ------------------------------ _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
On 17-11-2012 16:35:38 -0500, Medha Atre wrote:
dataset (in integer format) of 1.33 billion triples. /var/log/syslog shows mserver5 killed by the kernel "oom_signal (Out Of Memory)". ... So I wonder what changed from 11.9.7 to 11.13.3 that the bulk loader started crashing on one dataset of 1.33 billion triples, but works fine for 800 million triples.
It doesn't crash. Your operating system kills it. MonetDB can't do anything to a decision like that taken by your OS. Your OS probably feels like MonetDB is using too much memory. You could try adding some swap. A good rule of thumb is having twice as much swap as main memory. Fabian _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Actually the reason I found it mysterious is because if I load exact
same dataset using same SQL commands with MonetDB 11.9.7 (I have both
compiled on same machine), it works fine! OS doesn't kill it. The peak
resident memory utilization goes up to 6.3 GB or so, and then drops
below, with swap remaining pretty much empty (this is observed with
MonetDB 11.9.7).
I have 8 GB of RAM and 4 GB of Swap space.
If you could please confirm that the data format remains the same and
I can use 11.9.7 for loading the data and 11.13.3 for querying, it
would be great (as I need to run some experiments which cannot wait).
On Sat, Nov 17, 2012 at 4:40 PM, Fabian Groffen
On 17-11-2012 16:35:38 -0500, Medha Atre wrote:
dataset (in integer format) of 1.33 billion triples. /var/log/syslog shows mserver5 killed by the kernel "oom_signal (Out Of Memory)". ... So I wonder what changed from 11.9.7 to 11.13.3 that the bulk loader started crashing on one dataset of 1.33 billion triples, but works fine for 800 million triples.
It doesn't crash. Your operating system kills it. MonetDB can't do anything to a decision like that taken by your OS. Your OS probably feels like MonetDB is using too much memory. You could try adding some swap. A good rule of thumb is having twice as much swap as main memory.
Fabian
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Medha, some of the MonetDB internal virtual memory mamagement has changed since version 11.9.7 (Apr2012-SP2), mostly to clean things up and --- for the workloads we tested --- improve scalability. During which part of you extended load process does MonetDB get killed by the OS? Already during the initial copy into, or only during on of the insert statements? BTW, instead of create table lubm1b_p1(sub int, obj int); insert into lubm1b_p1 select sub, obj from lubm1b where pred=1 order by sub, obj; you could also simply use create table lubm1b_p1 as select sub, obj from lubm1b where pred=1 order by sub, obj with data; Stefan On Sat, Nov 17, 2012 at 05:19:44PM -0500, Medha Atre wrote:
Actually the reason I found it mysterious is because if I load exact same dataset using same SQL commands with MonetDB 11.9.7 (I have both compiled on same machine), it works fine! OS doesn't kill it. The peak resident memory utilization goes up to 6.3 GB or so, and then drops below, with swap remaining pretty much empty (this is observed with MonetDB 11.9.7).
I have 8 GB of RAM and 4 GB of Swap space.
If you could please confirm that the data format remains the same and I can use 11.9.7 for loading the data and 11.13.3 for querying, it would be great (as I need to run some experiments which cannot wait).
On Sat, Nov 17, 2012 at 4:40 PM, Fabian Groffen
wrote: On 17-11-2012 16:35:38 -0500, Medha Atre wrote:
dataset (in integer format) of 1.33 billion triples. /var/log/syslog shows mserver5 killed by the kernel "oom_signal (Out Of Memory)". ... So I wonder what changed from 11.9.7 to 11.13.3 that the bulk loader started crashing on one dataset of 1.33 billion triples, but works fine for 800 million triples.
It doesn't crash. Your operating system kills it. MonetDB can't do anything to a decision like that taken by your OS. Your OS probably feels like MonetDB is using too much memory. You could try adding some swap. A good rule of thumb is having twice as much swap as main memory.
Fabian
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- | Stefan.Manegold @ CWI.nl | DB Architectures (INS1) | | http://CWI.nl/~manegold/ | Science Park 123 (L321) | | Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) | _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
participants (3)
-
Fabian Groffen
-
Medha Atre
-
Stefan Manegold