[Monetdb-developers] Another big group by query

Stefan de Konink stefan at konink.de
Sun Apr 12 20:45:45 CEST 2009


Stefan Manegold wrote:
> load is 1.0 --- i.e., one thrad full throttle --- unless it is a "fake" load
> due to a Dead/Dummy/zombie process that is (e.g.) waiting for I/O --- in
> top, type "1" to get the summaries for all cores and "H" to list all threads
> and "u"+[Enter] to list processes of all users; then "P" to order on CPU
> usage and report; then "M" to oder on memory usage (34g res is IMHO
> everything but "empty") and report.

I am rerunning the query with having > 2; basically same situation.

top - 20:46:37 up 2 days, 11:03,  8 users,  load average: 1.02, 1.01, 1.10
Tasks: 283 total,   1 running, 282 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu1  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni, 93.0%id,  7.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu6  :  0.3%us,  0.3%sy,  0.0%ni, 92.4%id,  6.9%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:  66113464k total, 39815632k used, 26297832k free,   438728k buffers
Swap: 134215032k total,    89016k used, 134126016k free,  8093920k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 

11870 konink    20   0 51.7g  33g 5.3g D  0.3 53.8  10:16.09 mserver5

In most cases mserver is the biggest; it seems to be one thread.

>> Is there something that would be interesting to look at?
> 
> Basically, it would be great to know which MAL statement is currently being
> executed on which inputs --- prefixing your SQL statement with TRACE is one
> option (though I don't know whether that flushes it's output instantly; if
> not, we should consider adding such functionality excatly for such "hanging"
> situations --- in any case, it list only a statement after it has finished;
> hence, comparing the TRACE output with that of EXPLAIN is required); running
> in the MAL debugger (prefix SQL statement with DEBUG) is the other option
> (though I don't know, whether the MAL debugger has some "automatic single
> stepping/tracing" functionality ...)

I'll go play with this too.


Stefan




More information about the developers-list mailing list