By: Christopher Moeller
Abstract: Troubleshooting FAQ for Optimizeit Profiler on Linux
If your DISPLAY environment
variable is set to a display that does not exist, the OptimizeIt script fails
with the message "Class not found: intuitive.optit.profiler.App". This message
is sent by the virtual machine that OptimizeIt uses and is bogus. Make sure
to set your DISPLAY to a correct value.
For example on a machine named asterix, the DISPLAY is set with the command:
My application starts correctly, however an alert explaining that Optimizeit
failed to attach is displayed.
Optimizeit uses a default
connection time-out of 20 seconds to attach to the virtual machine.
In some environments, the Optimizeit audit system may require more than 20 seconds
to initialize. If this happens, select "Preferences" from the edit menu, select
the "Launch" section and increase the connection time-out value.
My application ran successfully, however the Optimizeit profilers are not working
correctly. Most of the profiler buttons are disabled. The CPU profiler shows
"No profiler information".
Optimizeit's profiler runs
inside the same virtual machine as the tested application. If the tested application
ends, the virtual machine exits, Optimizeit loses contact with its profiler
and cannot retrieve performance data (an alert saying "Test program exited"
pops up in Optimizeit).
To resolve this problem,
Optimizeit provides an option to disable the Java method System.exit(). This
option can be enabled either by using the option "Disable exit" in the settings
editor or by using the command line option "-noexit" (java ... intuitive.audit.Main
-noexit ...). That way the virtual machine does not exit when your application
ends. Use the Stop button in Optimizeit to exit the program when your profiling
When starting my application, I get an alert reporting a Class not found.
This error is very likely
related to a CLASSPATH setting problem. Open the setting editor from the File/Settings
menu, and make sure that the Class path section includes the paths to the packages
and classes required by your application.
When starting my application, the console reports a java.lang.UnsatisfiedLinkError.
This error may happen if
for some reason Optimizeit loads a library of an older version of Optimizeit.
If you have a previous version of Optimizeit installed, make sure that your
LD_LIBRARY_PATH does not point to this older version.
When starting my applet, the console throws an error: "java.util.MissingResourceException:
Can't find resource at java.util.ResourceBundle.getObject".
Optimizeit starts your applet
in the Sun applet viewer in order to profile it. The applet viewer throws that
error when the HTML file of your applet specifies the size of your applet in
percent. Make sure that the HTML file you are using to start your applet uses
hard values for the width and height.
The previous statements did not help. What should I do next?
The best way to investigate
the cause of the problem is to start your application from the command line.
In the following <OptItDir> is the directory where you installed Optimizeit
(e. g. : /home/jay/OptimizeIt)
In order to do that:
Attaching to a remote process does not work. The remote audit system throws
some exceptions and switching to the virtual machine information mode hangs
Optimizeit 4.11 adds several
new features and is not therefore compatible with earlier audit systems. Make
sure the remote process you are attaching to is from a 4.11 version of Optimizeit.
For additional developer
support options, please visit http://www.borland.com/devsupport
My application server no longer starts since I configured it with OptimizeIt.
First, make sure to check
the outputs and/or log files of your application server for any error message.
The virtual machine will not start if in your application server configuration,
the LD_LIBRARY_PATH (or native library path) does not include the OptimizeIt
lib directory. When you configure an application server with OptimizeIt and
JDK 1.2, you add the parameter -Xrunoii. When the virtual machine is started
with this parameter, it loads the OptimizeIt library liboii.so. If it cannot
find it in the LD_LIBRARY_PATH, the virtual machine fails to start. Make sure
that the LD_LIBRARY_PATH, or the library path of your application server points
to the OptimizeIt lib directory.
When I start the audit system from the OptimizeIt servlet, the servlet reports
that an error occurred while starting the profiler.
The OptimizeIt servlet should
show the error message that was generated when it started the audit system.
The most common causes for this problem are:
- the CLASSPATH does not include the OptimizeIt optit.jar package, located under
<OptItDir>/lib/optit.jar (where <OptItDir> is the directory where you
- the LD_LIBRARY_PATH does not include the OptimizeIt library directory <OptItDir>/lib
- the virtual machine has not been started with the parameters needed by OptimizeIt.
With JDK 1.1:
with Sun's JDK 1.3.1,
1.4 and IBM's JDKs:
- the audit system cannot
retrieve the demo key, see the note about the demo
key issue with JServ that applies to other application servers.
When I start the audit system from the OptimizeIt servlet in JServ, I get an
Internal server error. The Apache log reports the error "Premature end of
script headers: /servlet/OptimizeIt"
This problem can happen
with the OptimizeIt demo version if OptimizeIt cannot retrieve its demo key.
When you start the audit system from the OptimizeIt servlet, it checks your
demo license key. If it cannot find your demo key then it stops the virtual
machine. OptimizeIt retrieves the demo key from the .optit40 file located under
your home directory. This file is created the first time you run the OptimizeIt
GUI. If you have never run the OptimizeIt GUI with the same login as the user
used to run the server, starting the audit system from the servlet will fail.
You can either:
- start the OptimizeIt GUI once you have logged in as the same user as the one
used to run the Apache server
- specify the demo key using the parameter -DOIDEMO=demo-123-456-789. Add this
parameter at the end of the wrapper.bin.parameters= property in the jserv.properties
file (make sure to replace demo-123-456-789 with your demo key)
- run the setdemokey command included under the Optimizeit directory logged
in as the user used to run Apache JServ. For example:
If you are not running the
demo version of OptimizeIt and are experiencing this problem, it is probably
because you still have the demo version installed and that in the jserv.properties
file, the property wrapper.env=LD_LIBRARY_PATH= still points to the demo version.
Make sure that this property points the final version.
I cannot attach from the OptimizeIt GUI? Which port should I use to attach?
When I attach from the OptimizeIt GUI no profiling information is displayed?
When you integrate OptimizeIt
with an application server, you start the OptimizeIt audit system inside the
virtual machine of the application server. By attaching the OptimizeIt GUI to
the audit system, you profile the virtual machine of your application server
and get the profiling information for your servlets/JSPs/EJBs. OptimizeIt uses
a port to get the profiling information from the audit system running in your
application server. This port is only used by OptimizeIt and is not related
to any port of your application server. The default value for that port is 1470.
If you start your application with OptimizeIt from a script, the port is specified
in the script. If you use the OptimizeIt servlet to start the audit system,
the port is specified from the servlet. Make sure to use the correct port when
This problem occurs when
using J2SE 1.3.1 (JDK 1.3.1) without the correct options. When starting
a Java program or an application server with JDK 1.3.1, you need to add
the following option:
The CPU profiler does not work: when I stop the CPU profiler, it shows no results
and my application hangs
OptimizeIt comes with different
libraries for green thread virtual machines and native thread virtual machines.
If for some reason OptimizeIt loads the wrong libraries, the CPU profiler does
not work correctly and may very likely hang the application when you press the
Stop button. A typical situation is when you start your application with the
audit system from the command line or from a script, and you are using the JDK
1.2.x reference implementation. OptimizeIt for Linux defaults to green threads.
If your JDK uses native thread, you can choose to either:
- force the virtual machine to use green threads, by adding -green as the first
argument to the java invocation
- tell OptimizeIt to use its native thread library by adding -DOPTITTHR=native
and -DOPTITDIR=<OptItDir> to the java invocation (where <OptItDir> is
the directory where you installed OptimizeIt)
For example here is a command line starting the SwingSet demo with OptimizeIt
using green threads:
java -green -Xrunoii -Xnoclassgc
-Djava.compiler=NONE intuitive.audit.Audit SwingSet
And here, using native threads:
java -native -Xrunoii -Xnoclassgc
-Djava.compiler=NONE -DOPTITDIR=/home/jay/OptimizeIt -DOPTITTHR=native intuitive.audit.Audit
Note that the -native and
-green parameters should always be the first parameters. If they are not, the
virtual machine does not recognize them and fails to start.
While profiling my application, my application stops or crashes unexpectedly
Take a look at the external
console. It may give more information on what went wrong. If you do not have
an external console, it means you have not selected the option "Open a console"
in the settings editor. Make sure to select the option, and start the profiling
While profiling my application, the console shows a lot of lines saying "Should
not happen GCOPBuffer too small..." and then the virtual machine crashes
This problem happens when
the gc operation buffer is full. You can increase this buffer size with the
GCOPSIZE property. For example:
in order to use 4 Mb:
in order to use 6 Mb:
The default value is 2 Mb
and is generally large enough.
Add -DGCOPSIZE=n in the Extra Java parameters field of the settings editor if
you start the profiling from Optimizeit.
Add this property to the command line if you start your application from the
command line. For example:
java -classic -Xrunoii -Xnoclassgc -Djava.compiler=NONE -GCOPSIZE=6 intuitive.audit.Audit
The gc operation buffer
is a buffer that Optimizeit uses to take into account garbage collector actions.
When an action is received while the garbage collector is running, Optimizeit
cannot use malloc and increases this buffer. This is why a constant needs to
While profiling my application, the application stops, the console shows a java.lang.OutOfMemoryError
The virtual machine ran
out of memory. You can increase the size of the java heap by using the extra
java parameters -ms -mx (JDK 1.1) or -Xms -Xmx (JDK 1.2 and 1.3). For example
-Xms128m -Xmx128m sets the size of the java heap to 128 Mb.
If you are starting the profiling from Optimizeit, add those parameters in the
settings editor, in the field "Extra Java parameters".
If you are starting your application from the command line, add those parameters
to the command line. The following command line starts for example the profiling
of BusyApp with the JDK 1.3, setting the size of the java heap to 256 Mb:
java -Xrunoii -Xms256m -Xmx256m intuitive.audit.Audit BusyApp
Some X-servers, including
Exceed, have problems with Swing applications. Fonts are too big, windows are
the wrong size...
The best way to profile remotely is to run the OptimizeIt GUI locally. If you
profile remotely from your Windows platform on your Linux machine, make sure
to use OptimizeIt for Windows on the Windows platform.
Here are instructions on
how to configure Exceed 7 to display the right fonts with Optimizeit:
When I start the profiling from OptimizeIt, it forces the virtual machine to
use green threads. How can I use native threads?
OptimizeIt for Linux forces
the virtual machine to use green threads when you start the profiling from OptimizeIt.
If you want to use green threads, just set the THREADS_FLAG environment variable
to native before you start the OptimizeIt GUI:
Why can't I profile applets with my JRE?
When you profile applets
with JDK 1.2 or 1.3, Optimizeit runs your applet in the applet viewer using
oldjava rather than java, in order to avoid security exceptions. JRE 1.2 and
1.3 do not include oldjava. This is why Optimizeit requires a JDK to profile
However you can still profile applets with a JRE from Optimizeit by following
- edit the java.policy file of your JRE located under the lib/security directory
of your jre
- at the end of the file include the following lines:
grant codeBase "file:<OptItDir>/lib/optit.jar"
You should replace <OptItDir> with the directory wher
Server Response from: ETNASC03