Niagra, Daily Work

« previous entry | next entry »
Apr. 6th, 2009 | 11:57 am

First off, I have not been much of a of for Sparc in a number of years. Partly because I didn't feel like paying for the machines, and partly because I am not much of a fan of Solaris (the user space for development has a lot to be desired). In the last few months we have been working on getting Drizzle to work on Sparc/Solaris which has been an interesting adventure.

MySQL never compiled on Solaris without warnings, and it almost never could pass the full regression test system.

With Drizzle, I felt like if we were going to say we ran on Sparc/Solaris that I wanted to be able to say that we supported it without a bunch of exceptions.

It took us months... and I mean months to get things cleaned up for it. In the process I've gained a bit more respect for the platform (keep in mine... I was a big fan of SunOS, the predecessor to Solaris).

A few nice things I have noticed:

  • Compiling on the Niagra machine is fast. I run gmake -j and the thing just plows through the compile. Its faster then my 8proc Intel and way faster then my Mac Mini. What is impressive about this is that the Sparc is doing the compile with the write cache not enabled, while Linux and OSX are (hell... OSX has a fake sync() call, how lame is that?)

  • The Sun Studio compiler consistently finds more bugs/gives me better warnings then gcc. Sure, it lacks the built in atomic calls that gcc has, but thanks to working with the Sun Studio team we have been able to make use of their atomic.h and make a very simple compatibility layer. We don't handle our own assembler, we let the experts do that.

  • The more we reduce locks, the faster it gets. I am still arguing with some of the authors of the other MySQL type trees about this... there is still a concept that some locks are ok. I am finding that every turn even the most innocuous are still an issue. As an example, there is a lock around the query string for "show proccesslist". That one particular lock has turned out to be a real bane in production environments where you have lots of clients logging in and out... especially when you toss in monitoring. It took a few weeks to get rid of the locks there but we have them all gone now. It made a noticeable difference for some of the live usages of Drizzle (aka... just beyond benchmarks).

    All in all I am becoming a bit happier with the Sun/Solaris environment. I would prefer to just have Debian on the box, with an "apt-get solaris-kernel" to test against. It would give me a better apples to apples comparison. Valgrind and a number of other tools would be nice... but in general?

    I am finding that the environment is not as bad as I thought it would be to maintain, and that there are some actual benefits.
  • Link | Leave a comment | Share

    Comments {2}

    Do you use dtrace

    from: anonymous
    date: Apr. 25th, 2009 07:49 pm (UTC)
    Link


    Your comment about apt-get solaris-kernel leads me to think you
    are discounting one of the best features of Solaris.

    Reply | Thread

    Brian "Krow" Aker

    Re: Do you use dtrace

    from: krow
    date: Apr. 25th, 2009 08:10 pm (UTC)
    Link

    Why is that? I would presume that if you were able to do an apt-get for the Solaris Kernel that you would get Dtrace with that (and ZFS).

    The problem with Solaris is the user space.

    Reply | Parent | Thread