We are running JRun 4 and have lots of crashes. I am trying to understand where the problems are coming from and have modified the jrun.xml file to enable metrics logging.
This is what I'm seeing...
01/06 15:07:27 metrics Web threads (busy/total/delayed): 2/100/0 Sessions: 0 Total Memory=70720 Free=7464
01/06 15:08:27 metrics Web threads (busy/total/delayed): 1/100/0 Sessions: 0 Total Memory=66944 Free=9199
01/06 15:09:27 metrics Web threads (busy/total/delayed): 3/100/0 Sessions: 0 Total Memory=67456 Free=9644
01/06 15:10:27 metrics Web threads (busy/total/delayed): 3/100/0 Sessions: 0 Total Memory=63360 Free=8368
The book I've been reading (Adobe Coldfusion Anthology, Apress) suggests the "busy" number is the free memory in MB. The Adobe documentation says it's "Threads currently running". Which is correct?
Also, what does all this mean?
If I'm reading it correctly, I have 100 total threads, and 3 busy ones. So what are the other 97 threads doing if they are neither busy nor delayed?
I would advise a tool such as FusionReactor or SeeFusion for debugging ColdFusion stability problems. In my experience, crashes are related to memory allocation issues (not enough, too much, garbage collector settings, etc.). It also depends on what your application is doing and how many concurrent threads you have ColdFusion set to run. The tools mentioned above will give you a lot more visual insight into the server in real time so you can chase down the problems.
The thread busy/total/delayed is the number of thread currently being handled by Jrun.
Busy is in process, currently executing. Delayed is a thread that as been swapped out on the thread queue and is currently waiting to execute (typically cause there were no active thread available). It will stay there until an active thread frees up or until it reach the timeout value set in the configuration.
Didnt know about this book "Adobe Coldfusion Anthology" but, the administration documentation of Jrun (avaliable on the CD or web) was quite clear in the metrics.
I recomend u that include JDBC counters too, they are quite useful.
The last thing is knowing the memory, not only the total, but the different tipes, limits of architecture and so on...
Some metrics with the CPU, pages/s and similar, from the resource monitor on windows, often helps.
We runed jrun4 about 5 years, and got a huge quantity of problems, mainly in the develop area than in the system, nodaways, sometimes was our fault.
Last thing i recomend u, is that jrun4 has "cluster" hability, if u detect a bottle neck, u can always put a front IIS and 2 or 3 Jrun4 in the backend. Is quite effective.
Hope it helps.