Hi Jeremiah, Thanks again for the reply. I've been away for a few days hence the late response. Although it sounds like we are seeing the same characteristics as you did, like you, I'm not convinced we are seeing the same problem.
One final question - which version of Java are you running? Thanks very much for your help, Kevin. > Date: Wed, 31 Mar 2010 07:02:20 PDT > From: Jeremiah Campbell <jeremiah.campb...@jpmchase.com> > To: dtrace-discuss@opensolaris.org > Subject: Re: [dtrace-discuss] Analyzing java class loading with dtrace > Message-ID: <570590640.291270044175886.javamail.tweb...@sf-app1> > Content-Type: text/plain; charset=UTF-8 > >> Hi Jeremiah, >> >> Thanks very much for the reply. It was great to hear >> that at least one >> other person has had a similar problem. I have a few >> questions if you >> don't mind: >> >> 1) Was your Java performance problem related to this >> java variant of >> bug ID 6815915? It's not clear if that bug affected >> your diagnosis >> using dtrace or was the cause of the problem itself. >> i.e. did setting >> the environment variable DTRACE_DOF_INIT_DISABLE fix >> your performance >> problems or just enable you to get better results >> using dtrace? >> > We were definitely seeing this bug with our systems. The env variable > actually was the fix for the performance problem. The root cause of the issue > was that the Java Hotspot provider was loading a Dtrace helper that was > causing excessive mutex locks which was backing up threads on the CPU. We > were seeing high run-queue depth and low CPU utilization. Our issue wasn't > just that the JVMs were slow, but that they were slowing down the whole > server. > >> 2) Running "export DTRACE_DOF_INIT_DISABLE=true" >> before running my >> program in the shell doesn't seem to make any >> difference to the >> execution time. Is this how you implemented the >> workaround in your JVM >> startup scripts? >> > Yes, that is how we were enabling the work-around, specifically we were > setting it to "1", but I don't think it really matters either way. We had to > do this work around for all JVMs running on these servers. If it didn't > improve your performance, then perhaps it's unrelated. > >> 3) Excuse my ignorance, but what is "guds"? >> > > guds is a performance gathering script the Solution Center has traditionally > liked to have you run while you are experiencing problems. Though there are > multiple references to it via a search on bigadmin, I can't seem to find a > link to where to download it from. I obtained it via e-mail from a trouble > call at some point in the past. > > ----------- > Jeremiah _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
