(A) For thread 4: are you sure that it is waiting for anything, here is the iostat output, each observation one second apart: msync is called. Which is supposed to write your dirty pages to disk. This needs some investigation but would surely require a MacOS system.
disk0 cpu load average
KB/t tps MB/s us sy id 1m 5m 15m
0.00 0 0.00 0 0 100 0.04 0.05 0.00
So there is no cpu nor disk load. As for threads 5 and 6, one would think that the argument '--set gdk_nr_threads=1' constrains the number of clients that can connect. Even if that assumption is incorrect, right now there are no clients connected. During the lifetime of the server process though, there have been three possible client candidates: The number of threads is for processing, ie queries will use up to the specified number of threads to compute the query. Still each connected client will use its own thread.
- The server itself. We run the server with "bin/mserver5 --dbfarmUsers/howardshek/Onur-tmp/dbfarm --dbname=evatick_new --dbinit="include sql;" --set gdk_nr_threads=1 --daemon=yes ". So I am not sure if it qualifies as a client as well. Yes its a client but not on the sql level, so doesn't take up
On Thu, Mar 26, 2009 at 09:13:57AM -0700, Yue Sheng wrote: the lock we were worried about.
- Command line client ran by: "bin/mclient -d evatick_new -l sql". This runs a single sql command: "drop table Japan2008;" at the very beginning before the data load, and then I exit the client via Ctrl-D.
Should have finised ie would be strange if it still hangs on the lock.
- The R code using JDBC. At the moment, that process is killed too, so mserver5 might be waiting for some lock/semaphore/mutex to finally switch to the thread relevant to that particular client and do the cleanup.
Both the killed clients may be the cause but it would need a mac box etc
(B) My reply is getting long, and keeps getting rejected by the user list....
Sorry about that, but I guess we cannot fix sf. Niels