Hi Michael, I just double-checked your problem on my AMD Athlon 64 X2 running 64-bit Fedora Core 4, and everything works fine. I can shred and query XMarks documents up to 1.1 GB without problems (didn't try larger ones ;-)). We also have an Athlon 64 running 64-bit SuSE Linux 9.3 --- but I haven't had time to check that one, yet; I'll try to check it the coming days (a 500kB document works fine on that machine in our nightly testing...). In the meantime, I have some more questions for you: Which version of SuSE Linux and which version of gcc do you use? Which exact version of the MonetDB source do you use? - The released tar-balls from SourceForge (MonetDB-4.12.0.tar.gz & MonetDB-XQuery-0.12.0.tar.gz)? - The release source RPMs from SourceForge (MonetDB-4.12.0-1.src.rpm & MonetDB-XQuery-0.12.0-1.src.rpm)? - Source tar-balls or source RPMs from our daily-builds site (http://monetdb.cwi.nl/testing/projects/monetdb/Stable/.DailyBuilds./)? - A CVS checkout? (Which branch/tag?) Cheers, Stefan ps: I felt free to get let the Monetdb-users mailing list participate in the discussion, again... On Sun, Jul 09, 2006 at 05:14:23PM +0200, Michael Schmidt wrote:
Hi Stefan,
Sorry for the inconvenience! We'll update the info on the web site. And I feel free to propagate this discussion to the Monetdb-users list.
Thank you very much, I will also register there...
Wrt. your actual problem, I have a couple of questions, maily requesting more information to analyse the problem:
What kind of system are you running MonetDB/XQuery on? CPU (type, 32- or 64-bit)? amount of memory? free disk space? operating system (type, 32- or 64-bit)?
I'm running SuSe Linux 64-bit, here my /proc/cpuinfo... If there are any more details you need to know feel free to ask me again.
processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 3 cpu MHz : 2992.716 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr bogomips : 5994.87 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management:
How did you install MonetDB/XQuery? Using binary (.rpm or .msi) packages or compiling from source (tarball or from CVS)?
I compiled them from source.
Which queries are you running? Which of them are working with up to 50MB but fail with 100MB or more?
It's the same for all queries. I'm running the XMark test Queries #1, #6, #8, #13 and #20. Here one example Query: (XMark #1):
query1> { for $b in doc("/home/.../xmark.xml")/site/people/person where $b/person_id = 'person0' return <result> {$b/name} </result> } </query1>
Did you load/shred your document explicitely via the "shred_doc" MIL command on the Mserver console, or did you have them loaded/shreded implicitely on the fly via the fn:doc() XQuery function?
As running benchmarks where loading time should be included, explicit console loading is unsuitable. As seen above I load them from the query.
In the latter case, you could try whether the failing queries do work in larger documents once you increase the XML document cache limit by staring Mserver with "--set xquery_cacheMB=<size>" where size is large than the default 100, e.g., just larger than your largest document. (Admittedly, there is only very little "well hidden" documentation about the "--set" option(s) of Mserver; we're working on that...)
I tested "--set xquery_cacheMB=500" without success.
Kind regards Michael _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |