[Monetdb-developers] Concurrency Problem Mserver
Hello everybody,
as I am trying to get some experiments with PFTijah to work I encountered endless loops while executing some queries. Setting the debug_level to 1024 gave me a list of locks which were obviously competing about some resource. The attachment tries to describe what the start parameters, inputs and the log messages were.
Can somebody tell me whether that is a problem of mine, or a common one? And what a good approach to fix it would be.
Best regards & fijn weekend Robin
Robin Aly wrote:
Hello everybody,
as I am trying to get some experiments with PFTijah to work I
encountered endless loops while executing some queries. Setting the debug_level to 1024 gave me a list of locks which were obviously competing about some resource. The attachment tries to describe what
No, you only see what locks are set and released. In a database kernel locks should be set as short as possible. So, unless you are running multiple clients, this is not immediately pointing to a resource concurrency conflict.
the start parameters, inputs and the log messages were.
Can somebody tell me whether that is a problem of mine, or a common one? And what a good approach to fix it would be.
Best regards & fijn weekend Robin
gdb -args Mserver --set monet_daemon=yes --dbinit="module(pftijah); mil_start();"
/tmp/trec${i}.xq= let $opt := <TijahOptions returnNumber="1000" collection="PFX" algebraType="COARSE2" txtmodel_model="NLLR"/> for $q in doc("/local/alyr/dev/eval/clef-clsr-2006/clef-malach/topics/evaluation2006-en.xml")//top[3] let $q_text := pf:tijah-tokenize(exactly-one($q/title/text())) let $q_nexi := concat("//DOC[about(.,", $q_text, ")];") let $q_num := $q/num/text() let $result := pf:tijah-query-id($opt, (), $q_nexi) for $doc at $rank in pf:tijah-nodes($result) return string-join(($q_num, "Q0", $doc/DOCNO/text(), string($rank), string(pf:tijah-score($result, $doc)), "UTallEN"), " ")
MapiClient -l xquery </tmp/trec${i}.xq
Output getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604)
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D...
Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
Hello
as I am trying to get some experiments with PFTijah to work I
encountered endless loops while executing some queries. Setting the debug_level to 1024 gave me a list of locks which were obviously competing about some resource. The attachment tries to describe what
No, you only see what locks are set and released. In a database kernel locks should be set as short as possible. So, unless you are running multiple clients, this is not immediately pointing to a resource concurrency conflict.
yes, that what I thought as well. But these locks are repeatedly set and unset for multiple minutes (I assume the hex number at the end of the message is the representation for the lock?) The dump I sent is only a "short" extraction of what got logged.
Best regards, Robin
participants (2)
-
Martin Kersten
-
Robin Aly