Today, in this post I will describe some Oracle WebLogic and Cloud Control best practices I have learned in the last sessions. It’s always good to see what is advised by other people that are confronted with other or the same challenges.

 

Managing Oracle WebLogic Server with Oracle Enterprise Manager 12c

One session was related to the best pratices for managing WebLogic with Cloud Control 12c.

  • Use the administration functions:

Now you can, with Cloud Control 12c, do the WebLogic administration using its console. Starting and stopping the managed servers and applications were already possible but now you can do more like configuring the resources, deploying applications and so on.
As you are using the Cloud Control console you can sign in to several targets WLS servers. This means you have to enter each time the required password. By providing the credentials and saving them as the preferred ones (in Preferred Credentials) you avoid to enter the password each time.

  • Automate Tasks accross domains with predefined jobs:

Predefined jobs can be used to start automatically WLST scripts and this against one or more domains. Like with the WLS console you can register your actions into a .py script, update it for your new targets, create the job and set the schedule. This can obviously be a script for configuration but also for monitoring or creating statistics.

  • Automatic response to issue via corrective action:

By including corrective actions in templates you can apply them to managed servers. If the corrective action fails, by using rules you can send email in a second step to inform that there is an issue which need to be solved.

  • Use EMCLI to manage the credentials
  • Use APEX to query the Management Repository for reporting

 

Troubleshooting Performance Issues

An other session where best practices were explained was the session on “Oracle WebLogic Server: Best Practices for Troubleshooting Performance Issues”. A very helpfull session, all chairs in the room were occupied and some people had to stand, meaning the session was expected.

Some general tips:

  •  verbose:gc to find out if the performance issues are related to the garbage collection behaviour
  •  Dweblogic.log.RedirectStdoutToServerLogEnabled=true
  •  use the Java Flight Recorder (JFR)
  •  use Remote Diagnostic Agent (RDA)
  •  use WLDF to create an image of your system
  •  Thread/heap dumps to see how your application is working

One of the first action you have to do is to read the log files as they can show you which kind of errors are logged; stuck threads, too many open files aso.

The same application can behave differently whether it is deployed on WebLogic running on Linux or on Windows. For instance a socket can remain in TIME_WAIT 4 minutes in Linux but only 1 minute under Windows.

In case you encounter OutOfMemory errors, log the garbage collector information

-verbose:gc -XX+PrintGCDetails -XX:PrintGCDateStamps -XX:-PrintGCTimeStamps

More information can be found in the document referred by ID 877172.1

Thread Dump
To analyze your application you can create a thread dump

  •  under Unix/Linux: kill -3
  •  jstack
  •  WLST threadDump()
  •  jcmdprint_thread (for Java HotSpot)
  •  jcmdThread.print (for Java 7)

More information can be found in the document referred by ID 1098691.1

Once the thread dump has been created you have to analyze it.
For that, several tools are available

  •  Samurai
  •  Thread Dump Analyzer (TDA)
  •  ThreadLogic

Some best practices I already know; one tool I want to test now is ThreadLogic to be trained in case I have to use it in a real case.

Let’s see what will happen in the next days.