Bugs item #1654317, was opened at 2007-02-07 17:23 Message generated for change (Comment added) made by stmane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1654317&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PF/runtime Group: Pathfinder CVS Head >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Rittinger (tsheyar) >Assigned to: Stefan Manegold (stmane) Summary: XQ: following step kills Mserver (after 2h) Initial Comment: Running the attached query on a MBench generated XML file (sf=0.1, name=mbench0.1.xml) kills the Mserver after a long, long time with a Segmentation fault. (Using -d10 doesn't change a thing.) The reason either is the missing loop-lifting of the following step or the very large intermediate result (#ctx=2093, #nodes_in_doc=203089). Afterwards the database BACKUP is broken: !ERROR: force_move: link(bat/BACKUP/542.desc,bat05/542.desc)=-1 !OS: No such file or directory !ERROR: force_move: link(bat/BACKUP/544.desc,bat05/544.desc)=-1 !OS: No such file or directory !ERROR: force_move: link(bat/BACKUP/603.desc,bat06/603.desc)=-1 !OS: No such file or directory !ERROR: force_move: link(bat/BACKUP/553.desc,bat05/553.desc)=-1 !OS: No such file or directory !ERROR: force_move: link(bat/BACKUP/554.desc,bat05/554.desc)=-1 !OS: No such file or directory !ERROR: force_move: link(bat/BACKUP/570.desc,bat05/570.desc)=-1 !OS: No such file or directory !ERROR: BBPrecover: recovery failed. Please check whether your disk is full or write-protected. !FATAL: BBPinit: cannot properly process bat/BACKUP. Removing folder BACKUP helps. ---------------------------------------------------------------------- >Comment By: Stefan Manegold (stmane) Date: 2007-05-15 16:39 Message: Logged In: YES user_id=572415 Originator: NO Adding also kind-test push-down speeds up the queries to "kind of reasonable" times, given the huge intermediate result (loop_lifted_following_step_with_kind_test() returns 71476418/144619582 nodes in the ALG/MPS case): ALG now runs in ~25 secs MPS now runs in ~575 secs More improvement could (only?) be improved by also introducing "positional-predicate-push-down" (early-outs in the llscj algorithms), but this needs to be prepared in the compiler, first. I hence consider this one fixed and close it. Jan, please feel free to re-open it, in case it does not work for you, yet. No particular test added (see previous comment); (loop-lifted) following step in general is tested in several tests already. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2007-05-14 12:00 Message: Logged In: YES user_id=572415 Originator: NO added loop-lifted implementation of following step (preceding step will follow later) No extensive performance testing done, yet (of all standard benchmarks, only one query of XPathMark uses the following step). However, the query reported by JanR in bug report #1654317 "XQ: following step kills Mserver (after 2h)" (http://sourceforge.net/tracker/index.php?func=detail&aid=1654317&group_id=56967&atid=482468) now runs in ~45 secs instead of ~30 min with the ALG backend (on a 2 GHz Opteron with 8 GB RAM; Mserver grows to 4/8 GB res/virt); Unfortunately, the MPS version now grows to 14 GB and does not finish within 3 h (used to take 2 h requiring "just" 8 GB). Adding JanR's query as a test is not really an option, as it produces a 46 MB result (correctness check pending). ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2007-05-12 19:10 Message: Logged In: YES user_id=572415 Originator: NO On a 2 GHz Opteron with 8 GB RAM, the query seems to "work": compiled with optimization enabled and using 32-bit OIDs Mserver grows up to 8 GB, finishes after ~30 min (ALG) resp. ~2 h (MPS) (both CPU bound) without error, and produces some result (identical for MPS & ALG) --- did not check by hand, though, whether the result is correct or not. ---------------------------------------------------------------------- Comment By: Jan Rittinger (tsheyar) Date: 2007-02-07 18:03 Message: Logged In: YES user_id=993208 Originator: YES No to your first question. It basically is the following query (compiled with the algebra version): doc("mbench0.1.xml")//[EMAIL PROTECTED]/(let $child := ./child::*[1] return if (exists($child)) then $child else ./following::*[1]) (Based form the starting set apply the following step for all nodes that have no child (#ctx=2093) and throw away everything except the first one.) The whole thing took quite a while (~2 hours) and was always I/O bound. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2007-02-07 17:42 Message: Logged In: YES user_id=572415 Originator: NO Is the query one of the standard MBench queries? If so, which one? The "milprint_summer" version is known to have problems with MBench queries qa04, qj01, qj02, qj03, qj04; cf., http://monetdb.cvs.sourceforge.net/monetdb/pathfinder/benchmarks/MBench/Tests/All?view=log#rev1.2 http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/pathfinder/benchmarks/MBench/Tests/All Of course, Mserver should not segfault, but (at most) "fail properly"... Did you check/watch how big does your Mserver grows (grew) before crashing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1654317&group_id=56967 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
