[GE users] Solaris 7 submit host?

Andy Schwierskott andy.schwierskott at sun.com
Mon Sep 22 11:16:57 BST 2008

Hi Peter,

[anyone interesting in hearing a bit if malloc library issues on Linux
might want to read this email as well]

I just gave it a try - I does not work because SGE 6.2 binaires on Solaris
are linked against the libmtmalloc. The erorr I'm getting on a S7 host is:

% qstat
ld.so.1: /gridware/InhouseSystems/sge62/bin/sol-sparc64/qstat: fatal: libmtmalloc.so.1: version `SUNW_1.1.1' not found (required by file /gridware/InhouseSystems/sge62/bin/sol-sparc64/qstat)

% ldd bin/sol-sparc64/qstat
        libmtmalloc.so.1 =>      /usr/lib/64/libmtmalloc.so.1
        libmtmalloc.so.1 (SUNW_1.1.1) =>         (version not found)
        libdl.so.1 =>    /usr/lib/64/libdl.so.1
        libsocket.so.1 =>        /usr/lib/64/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/64/libnsl.so.1
        libm.so.1 =>     /usr/lib/64/libm.so.1
        libthread.so.1 =>        /usr/lib/64/libthread.so.1
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libmp.so.2 =>    /usr/lib/64/libmp.so.2

I don't know if there would be other obstacles running a binary compiled on
S8 (that's our courtesy binary buildhost). Likely not since SGE 6.1 binaries
seem to run ok (at least qstat/qmod etc.).

For Solaris 8+9 you need a patch to be installed - they are patches
for mtmalloc:


However it looks those patches are not available for Solaris 7. Possible
solution: Compile the Sparc binares without mtmalloc (and just normal malloc
library) on S8 and see if it works. If this does not work you might try to
compile the binaries on S7. However I don't know if that would still work at

The mtmalloc library was chosen as default malloc library for SGE 6.2 on
Solaris as an indirect outcome of having the scheduler running as a thread
in qmaster. With now two heavily CPU bound threads in qmaster we observed
significant performance impact with the standard malloc library. The qmaster
performance wand memory footprint with the mtmalloc library is much better
under heavy work. Client commands however would not see a significant (if
any) performance impact if linked against the standard malloc library.

On Linux we observe a similar problem: the standard Linux malloc library is
(to say it honestly) quite bad for heavily multithreaded applications in
terms of memory footprint and performance. There are situation where the
memory requirements can even run near out of control. The alternative is to
use a different malloc library. We've tested a couple of them (like
libhoard, Google malloc library, jemalloc). For licensing and portability
reasons we are considering to use the jemalloc library in the future for SGE
6.2 and/or later on Linux. jemalloc is also used by the Mozilla project e.g.
for Firefox 3. We are just starting the Sun internal legal processes to get
ok to use jemalloc in our builds.

The Linux malloc library issues are well known and not just SGE suffers from
it. It's surprising that these problems has been ignored by the Linux
community and big vendors behind Linux for so many years.


On Mon, 22 Sep 2008, Peter Jenkins wrote:

> All,
> I'm setting up a new SGE 6.2 install on Solaris 10 but we have one
> legacy system here still running Solaris 7 from which we need to submit
> jobs. Idealy I'd like to configure this as a normal submit host, but I'm
> open to other suggestions perhaps using a shell script ssh host keys?
> Does anyone know if modern SGE binaries work on Solaris 7?
> Thanks in advance,
> Cheers,
> Peter.
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list