Hi,
Is there a special reason there are no i686 RPM's anymore like there
were until 4.6.0_rc2?
I think it's a bit weird there are RPM's for the hobby OS 'FedoraCore'
but not for the much used server OS 'RedHat Enterprise 3 (and 4)'?
The FedoraCore (which Core?) needs libstdc++.so.6 whereas RHEL 3 only
has libstdc++.so.5 ...
There also seems to be no SRPM's.
Cheers,
--
Henk van Lingen, Systems & Network Administrator (o- -+
Dept. of Computer Science, Utrecht University. /\ |
phone: +31-30-2535278 v_/_
http://henk.vanlingen.net/http://www.tuxtown.net/netiquette/
Greetings!
Just doing some more digging around MonetDB, and have a couple of
questions.
(1) If I am managing multiple BATs that are (supposedly) synced, how do I
manage appends and the syncing?
For example, I have a_p1 = BAT[void, int] and a_p2 = BAT[void, int]
(a_p1 = <a> type things with property p1)
(a_p2 = <a> type things with property p2)
I wish to insert a new <a>=(1,2) thing. Do I do?
bat("a_p1").append(1);
bat("a_p2").append(2);
How do I ensure that the "voids" are always synced? Is this just
"assumed"?
What if I fail in the middle of operations (such that a_p1 has an extra
row) and stuck with dirty tables? Do I do a global "abort();" or a
"clean();" to get back to a safe state? Will this reset the seqbase?
(Is this documented someplace? I am trying to look at the architecture
docs but cannot find anything that concretely answers similar questions.)
(2) How does sync() work?
Do I do a:
sync(bat("a_p1"), bat("a_p2"));
once and only once? After every update/append to the tables?
There is the phrase "When two BATs effectively contain the same sequence
of head elements, we call them 'synced'. This is implemented by storing a
very large OID for each column. An update to the column destroys this
OID.". This sounds as if any update/append breaks the correspondence, and
also that it will limit the number of rows in the table (as an OID is a
32-bit number of 32-bit systems).
If I have 10 properties I am tracking, would I pick one as the "primary"
BAT, and sync() all others to it?
Regards!
Ed
Greetings!
In the architectural overview, I find the text: "Most memory resource
problems in MonetDB are easily avoidable by minimizing your open BAT
references (as discussed above) and making your access patterns cache
friendly (see the radix module)."
Is there anyplace that actually describes when a BAT is considered open?
Is it a scope thing (BATs are closed as soon as they are out of scope)?
Is a BAT open when I append/update? Does it close when I perform a commit?
If not, is there a way to specify "I am done, clean it out"?
I am noticing a large amount of open memory (approximately 500MB out of a
1GB system) being used by MonetDB. I have hand partitioned my BATs into
groups using a naming convention, but I am wondering if during inserts I
am somehow keeping open references to the BATs which may cause issues.
Is there a way to find out where memory is being allocated? Which BATs are
open?
Also, I am setting some of the larger BATs to STORE_MMAP. I notice in the
documentation that if I compress the heaps, then these must be set to
STORE_MEM. Is there a reason that when uncompressing the heap, that the
uncompressed version cannot be STORE_MMAP to avoid memory problems?
Regards!
Ed
Greetings!
Does anybody have any working example code using
mapi_prepare/map_prepare_array/mapi_execute_array showing the use of a
prepare along with array substitution?
I can get a sample piece working using mapi_execute. Trying
mapi_execute_array causes the test program to exit with an error code of
139 (the function does not seem to return, but causes an immediate exit).
Using mapi_prepare/mapi_execute_array, the program runs, but nothing is
changing in the database.
Regards!
Ed
Howdy all!
I had posted some questions regarding MonetDB, but have not received
feedback on any of them. Is there a more appropriate list I should be
posting to?
Regards!
Ed
Greetings!
Having some problems with the MonetDB server crashing.
- Start a server
- Have a client perform a lot of operations (_lots_ of BATs creation, bun
insertions, etc).
- Every 10,000 or so operations, perform a <commit();> on the client.
Total operations: approximately 7500 BATs, 17,000,000 BUNs.
- Do an <ls();> on the server to confirm all tables are clean.
- Now perform an <abort();> on the server with every table clean.
MonetDB>abort();
#GDKmmap(6553600) fail => BBPtrim(enter) usage[mem=736705664,vm=2137835808]
#
!mallinfo.arena = 35753984
!mallinfo.ordblks = 4454
!mallinfo.smblks = 0
!mallinfo.hblkhd = 122863616
!mallinfo.hblks = 33
!mallinfo.usmblks = 0
!mallinfo.fsmblks = 0
!mallinfo.uordblks = 15990816
!mallinfo.fordblks = 19763168
#GDKmmap(6553600) fail => BBPtrim(ready) usage[mem=736705664,vm=2137835808]
#
!mallinfo.arena = 35753984
...
(and so on)
Doing a <ulimit -a> shows:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14336
virtual memory (kbytes, -v) unlimited
Anybody have any ideas on why the server died? If I do it with less
(_much_ less) operations, it at least succeeds (even though there is a
lot of I/O occurring).
Regards!
Ed
