I actually meant 'JRun' logs which in my case are logs from the JVM as well :) but then it depends on your configuration, do you run coldfusion with JRun or something else? JRun logs are normally directly in the logs folder within the JRun directory.
On Tue, Jan 26, 2010 at 11:52 PM, Andrew Myers <am2...@gmail.com> wrote: > Hi Barry, > > Just wondering about the JVM logs you refer to. I'm not sure I've seen > these before. Any advice on what files I should be looking for? > > Thanks, > Andrew. > > Sent from my iPod > > > On 25/01/2010, at 5:54 PM, BarryC <barrychester...@gmail.com> wrote: > > There are many ways to go about finding what's going on in Coldfusion. >> Elaborating on what Kai was mentioning about metrics/garbage >> collection/memory.. >> >> Have you had a look in the logs from the JVM and ColdFusion to see if >> there are any error messages that might be related? >> >> The first thing you could do is turn on logging of long running >> requests (somewhere in coldfusion administrator) >> That might give you some clues as to what pages could be causing more >> load / cpu usage. >> >> Enable logging of metrics to see if you may have too many active >> handler threads (concurrent running processes of requests), you may >> need to configure some settings to optimise these values. >> >> The second thing you could do is do some thread dumps (you can do this >> either with a utility - there is one called StackTrace' or you can do >> it manually from a command prompt after you manually start coldfusion) >> Do several heap dumps every 10 seconds and see if there are common >> functions or pages coming up in the thread dump (the things that need >> more processing should come up more frequently in those logs). >> Thread dumps are generally used if you find you are getting >> bottlenecks in your application and you need to find what parts of >> your app could be doing the bottlenecking. So if you aren't getting >> long running pages then you may not need to do this. >> >> If you think it's memory related (and if you are getting tight on >> memory for your application, that will cause more 'Major' garbage >> collection events using more CPU) then you can enable garbage >> collection logging, a free analyzer tool called GCViewer >> http://www.tagtraum.com/gcviewer.html lets you get a graphical view of >> what's going on as a memory overview. If it looks like you have a >> memory problem, then you can generate heap dumps and use something >> like the Eclipse memory analyzer plugin (MAT) to view the heap dump >> log. >> Google will tell you how to generate heap dumps. >> >> An awesome profiling tool that I found very useful was Oracle's >> Jrockit Mission Control (used to be owned by BEA or something >> arather). It's free for development and you can do profiling with that >> and see pretty much everything that's going on in coldfusion. >> You do have to update your config file to point to that though, and it >> could be slightly dodgy running it in a production environment, it's >> more something you use in a development environment. >> >> There's a lot to learn when it comes to the under the hood performance >> and memory stuff but it's quite interesting and very good to know as a >> developer how all that stuff works. >> >> Barry >> >> >> >> On Jan 25, 4:20 pm, Andrew <am2...@gmail.com> wrote: >> >>> Hi Folks, >>> >>> My hosting company has just informed me that the CF7 instance for a >>> site I maintain is using about 65% CPU at the moment (on a Solaris >>> machine). The site uses quite a few frameworks - ModelGlue, >>> ColdSpring, Transfer and Javaloader. >>> >>> We have recently attempted to move this to CF8 but aborted the attempt >>> because it basically just ground the server to a halt. So I think >>> there is something more sinister going on here that I need to sort out >>> before we attempt that again. >>> >>> However I'm a bit stuck with where to go from here. The site has been >>> going along quite nicely until recently. Traffic has grown quite a >>> lot in the last 1-2 years which I'm sure is not unrelated. Just to >>> throw a few extra spanners into the works I *believe* this is a shared >>> server but I have no information on what else is running on it and >>> whether that could possibly be causing us problems. >>> >>> I know this is very very vague but I don't get a lot of info from our >>> hosting provider except that we are using up too many resources. >>> Perhaps we have just outgrown our current hardware, but I am not sure >>> how to confirm this. Any suggestions on what I could start looking at >>> to track down the source of the issues would be hugely appreciated. >>> >>> Andrew. >>> >>> P.S. I do have a development server which is identical except that it >>> only has 2GB RAM as opposed to the 4GB in production. Load testing on >>> this is definitely an option - I have used JMeter in the past but not >>> sure I have used it optimally. Anyone got any suggestions on load/ >>> stress testing tools? >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "cfaussie" group. >> To post to this group, send email to cfaus...@googlegroups.com. >> To unsubscribe from this group, send email to >> cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/cfaussie?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
