Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Troubleshooting Guide 11g Release 1 (11.1.1.5.0) |
1. Overview of Troubleshooting Directory Server Enterprise Edition
2. Troubleshooting Installation and Migration Problems
3. Troubleshooting Replication
4. Troubleshooting Directory Proxy Server
5. Troubleshooting Directory Server Problems
Getting the Core and Shared Libraries
Examining a Core File on Solaris
Troubleshooting an Unresponsive Process
Symptoms of an Unresponsive Process
Collecting Data About an Unresponsive Process
Analyzing Data About a Unresponsive Process: an Example
Troubleshooting Drops in Performance
Possible Causes of a Drop in Performance
Collecting Data About a Drop in Performance
Collecting Disk, CPU, and Memory Statistics
Collecting Consecutive Process Stacks on Solaris
Analyzing Data Collected About a Performance Problem
Analyzing the Access Log Using the logconv Command
Identifying Capacity Limitations: an Exercise
Troubleshooting an Active Hang
Possible Causes of an Active Hang
Collecting and Analyzing Data About an Active Hang
Troubleshooting a Passive Hang
Possible Causes of a Passive Hang
Collecting and Analyzing Data About a Passive Hang
Troubleshooting Database Problems
Possible Causes of Database Problems
To Troubleshoot a Database Problem
6. Troubleshooting Data Management Problems
7. Troubleshooting Identity Synchronization for Windows
8. Troubleshooting DSCC Problems
9. Directory Server Error Log Message Reference
This section describes how to troubleshoot a memory leak.
Memory leaks are caused by problems allocating memory, either in Directory Server itself or in custom plug-ins. Troubleshooting these problems can be very difficult, particularly in the case of custom plug-ins.
It is important to do the following before collecting data about your memory leak:
Disable any custom plug-ins
Reduce the cache setting to very low values
Enable the audit log
Once you have done the above, run the prstat -L utility and check the VSZ column if it grows.
Collect the generic Directory Server data, as described in Collecting Generic Data. This data includes the version of Directory Server that you are running, logs from the test run, in particular the audit log, and the Directory Server configuration file.
With the data you collected, you can now contact the Sun Support Center for assistance with your problem.
On Solaris systems, the libumem library is a memory agent library that is helpful for analyzing the cause of a memory leak. For more information about the libumem library, see the technical article at the following location: http://developers.sun.com/solaris/articles/libumem_library.html
Restart the Directory Server using the following command:
# SUN_SUPPORT_SLAPD_NOSH=true LD_PRELOAD=libumem.so \ UMEM_DEBUG=contents,audit=40,guards UMEM_LOGGING=transaction ./dsadm start
The libumem library is now loaded before the Directory Server starts, instead of using the Directory Server memory allocation.
Next, run the gcore command several times, once before the memory use started to grow and once after. The gcore command will dump a memory image in the current directory.
# gcore core.process-id
Finally, use the mdb tool to analyze the results.