6 Replies Latest reply on May 17, 2004 5:07 AM by lviz

    application on Xeon Dual CPU

    zhangj

      I have a J2EE application,I put it on a P4 machine,it consume about 90_100% cpu,but if I put it on a Xeon dual CPUs machine,it take only 30_40% CPU,how can I increase the CPU usage on Xeon son it runs faster?

        • 1. Re: application on Xeon Dual CPU
          zhangj

          ps this is a CPU centric application,basicly,it is a nested loop to construct a big string

          • 2. Re: application on Xeon Dual CPU
            lviz

            hello zhangj

            java uses only one cpu on the dual machine so if
            it shows 50%; 1 cpu runs on 100%.

            cheers
            L

            • 3. Re: application on Xeon Dual CPU
              lviz

              start a second java-vm/jboss
              and it will use the other 50% of you dual machine.

              L

              • 4. Re: application on Xeon Dual CPU
                gorano

                If thats true LViz, it's quite bad news if we have no intention to run more than one JBoss instance on a multi processor machine.

                If not supported in the JVM it must be a way of configuring the server
                to use both processors (JVM doesn't have to know about it), or?

                /G

                • 5. Re: application on Xeon Dual CPU
                  lviz

                  hi
                  depends on your os and your vm.

                  os?
                  vm?

                  cheers
                  L

                  • 6. Re: application on Xeon Dual CPU
                    lviz

                    from sun java hotspot performance faq..


                    My program isn't scaling with the number of processors.

                    Scaling problems could be a multitude of things. First, your application may not be written in a scalable manner (if you use a lot of synchronization, for one example, or if you have only one thread, as another). It may also be that you are utilizing OS system resources which are not scalable. Finally, if you have many threads, it may be that garbage collection is getting in the way. Garbage collection in HotSpot is single threaded (a concurrent and parallel garbage collector will be available in version 1.5) which means that your Java threads must be suspended for each one. First, make sure your application isn't doing its own garbage collection via a "System.gc()" explicit call. This used to be a popular style when generational garbage collectors didn't exist (the 1.x versions of Java at Sun) but should no longer be necessary. Next, turn on -verbose:gc to view and time the collections. This will help determine if garbage collection is the problem. If it is, check out the question on pause times above to help with garbage collection issues. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

                    The threading model used by the VM may be a problem. The Solaris threading model uses a many to many mapping of Java threads to OS threads. In other words, a single Java thread may be mapped to different OS threads during its lifetime, and any given OS thread may have more than Java thread.

                    You can try reducing the variability by using -XX:+UseBoundThreads. This will map the Java thread to a particular Solaris LWP (this option is not available on Windows/Linux).

                    One can also attempt, if on Solaris 8, to use the alternate libthread in /usr/lib/lwp /usr/lib/lwp/libthread.so will switch to a one level thread model. This disallows user level scheduling, as only the kernel will schedule the thread. If the thread blocks on a mutex, the LWP will block in the kernel. In general if there is high lock contention then the standard libthread will work better than the alternate libthread as the alternate libthread's operations are heavier weight.