-
Title
Is using "LD_PRELOAD libumem.so" in place of the standard memory management library on Solaris 10 -
Description
QUESTION: Is using "LD_PRELOAD libumem.so" in place of the standard memory management library on Solaris 10 supported/recommended?
We noted that our FMS is running slowly. The FMS is running in a Solaris 10 zone. We ran the "prstat -mL -u foglight" command to check for microstate locks (light weight process locks), and found many. The fms processes are spending large amounts of time waiting on locks. Please see the example line from the prstat output below:
1 77400 libc.so.1`libc_malloc_lock libzip.so`Java_java_util_zip_Deflater_deflateBytes+0x2c4
The memory management shared object doesn't work well with large amounts of threads. We are using a m9000 Solaris host which is a massive machine with many zones. The default library is the libc.so which has the default memory management library in it. The libumem.so library is also supplied by Sun/Oracle with the Operating System and is installed by default. Sun/Oracle also recommend the use of libumem.so for applications that are heavy on memory usage.
Using the LD_PRELOAD utility to load libumem.so in place of the standard library can provide a workaround for the memory management issue. We have been using this workaround with various applications since about 2004. We have seen it crash once with one application. We would like to set LD_PRELOAD libumem.so in the environment and then start up the FMS, but we would
-
Resolution
ANSWER:
Foglight is not tested with anything outside the standard libraries. If you would like to use non-standard libraries, you are free to do so, however, Quest Foglight support does not recommend it because Quest QA has not tested Foglight with non-standard libraries.
The FMS will still be supported if you run it with libumem.so, but if Quest Foglight Support suspects a problem is caused by the libumem.so library we will ask you to revert to the standard library.