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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Rittinger (tsheyar)
Assigned to: Nobody/Anonymous (nobody)
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-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

Reply via email to