Bugs item #1982101, was opened at 2008-06-02 15:14
Message generated for change (Comment added) made by stmane
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1982101&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 0.24
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wouter Alink (vzzzbx)
Assigned to: Nobody/Anonymous (nobody)
Summary: XQ: slowing down
Initial Comment:
MonetDB/XQuery slows down after each query. It seems to be related to the
complexity of the query. If running a simple query (for example "1+1") 10000
times, the first time it executes in .01 second. Then the execution time
gradually increases. The last time it executes in .05 seconds. Only restarting
mserver seems to reduce the execution time again to .01
The following script illustrates the problem:
n=0;
while [ $n -le 10000 ]
do
if [ $(($n % 100)) -eq 0 ]
then
clear
echo "Iteration $n"
time echo '1+1' | mclient -lxq > /dev/null;
fi
echo '1+1' | mclient -lxq > /dev/null;
n=$(($n + 1))
done
Is this expected behavior? (i know that 10000 times executing 1+1 is not really
a good example, but the same behavior is observed with more complex queries)
i'm using: MonetDB-preJune supersourcetarball (28-may-2008), Fedora Core 8,
64bit-oid
----------------------------------------------------------------------
>Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 17:18
Message:
Logged In: YES
user_id=572415
Originator: NO
At least with the tiny "1+1" query, I cannot reproduce the problem; time
per query stays at .01 sec:
========
$ n=0 ; while [ $n -le 10000 ] ; do if [ $(($n % 1000)) -eq 0 ] ; then
echo "`date` Iteration $n" ; echo '1+1' | time mclient -lx -t >/dev/null ;
fi ; echo '1+1' | mclient -lx -t >/dev/null ; n=$(($n + 1)) ; done
Tue Jun 3 16:49:16 CEST 2008 Iteration 0
0.00user 0.00system 0:00.01elapsed 26%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:49:28 CEST 2008 Iteration 1000
0.00user 0.00system 0:00.01elapsed 27%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:49:39 CEST 2008 Iteration 2000
0.00user 0.00system 0:00.01elapsed 36%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:49:51 CEST 2008 Iteration 3000
0.00user 0.00system 0:00.01elapsed 30%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:50:02 CEST 2008 Iteration 4000
0.00user 0.00system 0:00.01elapsed 20%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:50:14 CEST 2008 Iteration 5000
0.00user 0.00system 0:00.01elapsed 36%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+578minor)pagefaults 0swaps
Tue Jun 3 16:50:25 CEST 2008 Iteration 6000
0.00user 0.00system 0:00.01elapsed 30%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:50:37 CEST 2008 Iteration 7000
0.00user 0.00system 0:00.01elapsed 10%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:50:49 CEST 2008 Iteration 8000
0.00user 0.00system 0:00.01elapsed 20%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
Tue Jun 3 16:51:00 CEST 2008 Iteration 9000
0.00user 0.00system 0:00.01elapsed 20%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+578minor)pagefaults 0swaps
Tue Jun 3 16:51:12 CEST 2008 Iteration 10000
0.00user 0.00system 0:00.01elapsed 30%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+577minor)pagefaults 0swaps
========
The above log actually represents the 3rd or 4th 10k query on on the same
Mserver session, i.e., I actually executed 30k-40k queries without any
visible performance degradation...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1982101&group_id=56967
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
