4 Replies Latest reply on Dec 3, 2008 5:40 PM by rhills

    JBoss AS 4.2.3.GA + Seam 2.1.0.GA - 1 hit = 100% CPU

    rhills
    rhills Dec 2, 2008 12:28 AM

      We're trying to work out why a single page hit on our application pushes the CPU to 100%.

      Our setup is JBoss AS 4.2.3.GA + Seam 2.1.0.GA. We're using the APR and serving over HTTPS.

      The 100% CPU hit happens with any page that does any "work" (DB lookup + rendering results). It occurs after multiple hits on the same page. It occurs on two dev machines and a staging server.

      The web application feels very slow for a single user, even running off the staging server. I've got to do performance testing at some stage, but there seems little point while it's so sluggish for a single user.

      WRT memory, my dev machine has 2GB of RAM. The JVM config is: -Xms300m -Xmx300m -XX:NewSize=100m -XX:MaxNewSize=100m and profiling IAW http://www.cecmg.de/doc/tagung_2007/agenda07/24-mai/2b3-peter-johnson/index.html suggests that the GC process is running smoothly. On this machine, there is about 800MB RAM free before JBoss startup and our app doesn't seem to consume the 300MB heap (not in short runs anyway).

      I've been through the server optimisation/slimming process detailed at http://www.jboss.org/community/docs/DOC-10217, with minimal impact on this issue. Not that I was surprised as most of the recommendations in that doc appear to be targeted at scaling performance and our problem is with a single user.

      When I profile the classes to try and establish what is causing the CPU hit, 95% of the CPU time vanishes in two APR methods: org.apache.tomcat.jni.Poll.poll and org.apache.tomcat.jni.Socket.accept.

      Almost no CPU time is consumed by our own classes.

      The profiling is done with JProfiler and AFAICT, the CPU time recording is only for the JBoss server, not other apps on this machine (browser etc.). For the record, the DB accessed by this app is on a separate server and all tables are quite small (the largest is 12K rows, most are < a few hundred records).

      I'm not sure what this is telling me. Is this normal behaviour for JBoss serving HTTPS or have we got our server configuration all wrong? Does anyone have any thoughts on where I should look next?

      • 2992 Views
      • Tags:
        • 1. Re: JBoss AS 4.2.3.GA + Seam 2.1.0.GA - 1 hit = 100% CPU
          noelo
          noelo Dec 2, 2008 5:41 AM (in response to rhills)

          If this is on windows, run it without the apache portable runtime (apr)....
          I've seen this happen problem happen on windows before with tomcat...

            • Actions
          • 2. Re: JBoss AS 4.2.3.GA + Seam 2.1.0.GA - 1 hit = 100% CPU
            rhills
            rhills Dec 2, 2008 8:28 PM (in response to rhills)

            It is on Windows (XP). I've not seen anything official about the APR being CPU-intensive on the Windows OS, is this a known issue?

              • Actions
            • 3. Re: JBoss AS 4.2.3.GA + Seam 2.1.0.GA - 1 hit = 100% CPU
              noelo
              noelo Dec 2, 2008 8:41 PM (in response to rhills)

              I have seen high CPU usage on XP and Tomcat running using the APR.
              This *may* be the cause of your issue, try it out without the apr and see....

                • Actions
              • 4. Re: JBoss AS 4.2.3.GA + Seam 2.1.0.GA - 1 hit = 100% CPU
                rhills
                rhills Dec 3, 2008 5:40 PM (in response to rhills)

                 

                "noelo" wrote:
                I have seen high CPU usage on XP and Tomcat running using the APR.
                This *may* be the cause of your issue, try it out without the apr and see....


                OK, I've removed APR and HTTPS from the equation and although the app performance has improved slightly we're still seeing 100% CPU usage with a single hit on each of our dynamic pages that I've tested.

                I've profiled a single hit on a single page that takes about 10 seconds from clicking on a "Search" button to the end of page rendering (25 result rows shown). Without the APR, we get a little more visibility in our profiling results, and around 7 of the 10 seconds are spent rendering the result: com.sun.facelets.FaceleteViewHandler.renderView. Below that, there is no standout time hog. Our own classes consume about 100ms of the total unfortunately so there doesn't seem to be much we can do there.

                We'll play around with one of our views and by process of elimination see if we can pinpoint the problem.



                  • Actions