Hi all,
I downloaded a copy of the 11.15.7 (Feb2013 SP2) source and compiled and
installed it. I also have a copy of the same version of MonetDB installed
from elsewhere (I'm not sure where now--sorry).
Now, when I run the "old" version of Monet (the one I didn't just compile)
and create a DB (`monetdb create test`), release it, and start it,
everything works fine. The log looks likes this:
...
MSG merovingian[32695]: starting database 'test', up min/avg/max: 0s/0s/0s,
crash average: 0.00 0.00 0.00 (0-0=0)
MSG control[32695]: (local): started 'test'
MSG test[32705]: arguments: /usr/local/bin/mserver5 ...<snip>...
...
However, when I run with my compiled version (using `configure
--program-suffix=-vanilla`), starting a created DB does not call
mserver5-vanilla, but rather monetdbd-vanilla, which is the incorrect
command, and thus the database cannot start. (If I manually run
mserver5-vanilla, it works fine.) The log looks like this:
MSG merovingian[2616]: starting database 'test', up min/avg/max: 0s/0s/0s,
crash average: 0.00 0.00 0.00 (0-0=0)
MSG test[2625]: arguments: /usr/local/bin/monetdbd-vanilla ...<snip>...
MSG test[2625]: usage: monetdbd [ command [ command-options ] ] <dbfarm>
MSG test[2625]: where command is one of:
MSG test[2625]: create, start, stop, get, set, version or help
MSG test[2625]: use the help command to get help for a particular command
MSG test[2625]: The dbfarm to operate on must always be given to
MSG test[2625]: monetdbd explicitly.
ERR test[2625]: monetdbd: unknown command:
--dbpath=/home/breilly/db/farm-vanilla/test
MSG merovingian[2616]: database 'test' (2625) has exited with exit status 1
ERR control[2616]: (local): failed to fork mserver: database 'test' appears
to shut itself down after starting, check monetdbd's logfile for possible
hints
I tried just now to compile without the suffix, but in a different
directory (i.e. `configure --prefix=$HOME/apps`), and it worked fine, as
with the first version above. I'm not sure why the one with the suffix
fails in the way it does: it's not like it tries to find
"mserver5" (without the suffix) and fails. Instead, it successfully finds a
real command with the suffix, but it's the wrong one.
I have also tried simply symlinking to my suffixed program with
non-suffixed name (i.e. `ln -s $HOME/apps/bin/monetdbd-vanilla
$HOME/apps/bin/monetdb`, for each of monetdbd, monetdb, mclient, and
mserver5), and this also works. However, it does not run the correct
version of mserver5: it runs /usr/local/bin/mserver5, rather than my local
copy at $HOME/apps/bin/mserver5. Is there some environment variable that
I'm not setting correctly? ($HOME/apps/bin is in my PATH).
Please let me know if there is any more information that I can provide for
you. Thanks in advance for your help.
Regards,
Ben Reilly
Thanks. May I know size of your database?
--- Original Message ---
From: "Brandon Jackson" <usbrandon(a)gmail.com>
Sent: June 20, 2013 12:09 PM
To: "Communication channel for developers of the MonetDB suite." <developers-list(a)monetdb.org>
Subject: Re: Monetdb - production users
We are running MonetDB in our enterprise in a production environment. It
works well. There are nuances.
We do a lot of bulk loading, so we picked a time during the day to shut
MonetDB down and restart it.
The reason, memory fragmentation, does occur and in our experience would
cause the database to fail and lock up. It will stop accepting connections.
Our database health gradually and constantly decreases. Although I can say
we have never received wrong answers from the database or had any obvious
effects from poor database health. We periodically recreate the entire
database to get the health of the database back up to 100%. Essentially we
use MonetDB as a fast query database and not the primary database for
maintaining the integrity of our data. There is no repair utility for the
database. We're still learning how and if we should report issues like
this because it happens gradually and the log has some splat marks " ***
glibc detected *** /usr/bin/mserver5: corrupted doubly-linked list:
0x00007fa12411f4d0 *** and *** glibc detected *** /user/bin/mserver5:
double free or corruption (!prev): 0x00007fa12411f4d0 *** in it.
Like anything else, I think you learn to live with whatever tools you are
using and play into the strengths and avoid the weaknesses, reporting them
and hoping they can get patched up eventually.
Brandon
On Thu, Jun 20, 2013 at 9:29 AM, Baskar Duraikannu <
baskar.duraikannu(a)outlook.com> wrote:
> I would like to know whether any enterprise is running MonetDB outside
> research community. Please help.
>
> _______________________________________________
> developers-list mailing list
> developers-list(a)monetdb.org
> http://mail.monetdb.org/mailman/listinfo/developers-list
>
>
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
Good morning.
I recently installed and tested monetdb with a sample dataset and it performed really well. Then I came across the below posthttp://stackoverflow.com/questions/7435235/is-it-worth-trying-monetdb
Above post talks about non-availability of buffer manager in MonetDB. Has this changed?
Good afternoon,
I have 2 questions :
- 1st question
I have a csv file with 300000000 million lines.
when I load it in a MonetDB table, it takes more than 16 hours, whereas in Oracle it only takes 15 minutes. Where is the problem?
I use mclient as follows :?
mclient -u user1 -d demo -ims -s " COPY 300000009 RECORDS INTO LINEORDER FROM STDIN USING DELIMITERS '|','\n'" - < D:\SSB\LINEORDER.tbl
?for information I use :
MonetDB5
Windows
Memory : 16 Go
There are two constraints : primary key and foreign key on the table prior to loading data?
2nd question :
how inner joins are made in MongoDB?
cordialy.
Hi guys:
In my case , original data 8G bytes, but after plenty of query, the disk space usage is 361G bytes. The query is simply, first five UNION ALL, then fetch the result. When the query is running, I use vmstat to watch the IO status. When the database becomes larger, the BI and BO number increase very large too, for example bo 355224, bi 27392. And the query cost ten times longer than before!
After rebooting the database, the database disk space was reduced to its original data size, 8G. It seems too much runtime data was produced. How can I solve the problem or avoid the problem!
Thanks,Jason
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
hi all,
I am tracing the select of GDK, it's so complex, and In every type,
there is a nocheck variable, who can help me explain the nocheck variable,
what's the meaning of it? :)
--
Best Wishes!
zhanglei