Paul Humphreys's Weblog
News and Views

20080416 Wednesday April 16, 2008

Sunray Server strategy shift

Chris and myself have described our high regard for the SunRay technology and how we use it in the office and at home. We have a Solaris10 'FCS' server which runs the latest Solaris10 update release. This is for our users who do not want to be on the bleeding edge. This is still a E4900 with two system boards and a total 128GB of memory. We then had another E4900 with the very latest Ultrasparc processors from the lab pool keeping them warm until they are needed for customer support. This platform was divided into two domains. These two domains would be upgraded in turn to new builds of what we call Solaris Nevada. This exposes us to the latest technology and fixes that I believe always go into Nevada first before going back into say the Solaris 10 patch or feature gates. Anyway this was all good until someone said why not have a x86 box? So we put in a well configured V40Z. This extends the time between upgrades of each of the servers (six weeks) and is good as it means the server runs longer hopefully finding memory leak problems or other issues that are only found when systems run for longer periods of time.

What we are not expecting to find was an Xsun bug you would only see on x86 platforms.

When we announced the first Niagara2 machines we felt duty bound to give one a go and within hours of running one we had a really interesting bug Tim looked at that and again you would only see in Nevada and on the Niagara2 platform. Within a few weeks we then had another bug this time you would only see on the latest Ultrasparc IV+ processors again on Nevada. We have also found and logged several application bugs and some relating to the Gnome desktop. The oddest one I logged was BugID 6564048 with the title of Nevada lp prints non-existent files! So given all this tangible benefits of running these platforms we have decided to keep:

Sunfire V890 Server replacing the E4900 - this is a smaller size box - with the latest Ultrasparc IV+ that you can get for this box.

Sunfire T5220 server eight cores, 64GB memory.

And the Sunfire V40Z server.

Should be interesting...

( Apr 16 2008, 12:00:01 AM PDT ) Permalink Comments [7]

Trackback URL: http://blogs.sun.com/paulhu/entry/sunray_server_strategy_shift
Comments:

Along with the new x86 server, have you got anyone utilising Multihead Groups of multiple DTUs (i.e. two or three SR2's rather than an SR2FS)?

At the University I work for we run a number of Sun Rays (most of them in terminal groups of 2 or 3 DTUs) for IT staff and we've noticed a painful memory leaking issue with Xinerama turned on. The servers are all x86 boxes with a build of Nevada running on them. Multihead seems to be a feature that gets somewhat less attention than the rest of the Sun Ray software, so I'm interested to see if anyone within Sun is really making use of it.

Cheers!

Posted by Joshua Clulow on April 16, 2008 at 12:50 AM PDT #

We do use multihead here too and Xinerama but not as much as we used to as people only have one screen at home so it is not as popular as it used to be. I assume you are finding Xsun is gobbling up the memory and as you are running Nevada I am not sure how you go about logging a bug - we can internally? If you provide the evidence and you can't log a bug I don't mind helping you if I can.

Posted by Paul Humphreys on April 16, 2008 at 02:25 AM PDT #

Yes, essentially Xsun gets bigger and bigger when run in Xinerama mode (utxconfig -x on) where-as it remains quite small and is not a problem for users utilising three non-knitted DTUs (utxconfig -x off, so three separate X11 "screens" with only the cursor able to pass between them). xrestop can't see it as being attributable to any particular pixmaps, and nothing short of bouncing Xsun will clear up the usage. All of the memory is listed as being within a large heap section (pmap -x). We also haven't been able to tie down specific apps or behaviours as being the cause because it's been fairly erratic behaviour with the one constant being eventually the machine will run out of memory.

I'll pull some evidence together and drop you an e-mail! Thanks.

Posted by Joshua Clulow on April 16, 2008 at 02:32 AM PDT #

What version of Nevada are you running?

I have reason to believe you want to be above 37 AND 49

Posted by Paul Humphreys on April 16, 2008 at 06:19 AM PDT #

There is one more bug with Xorg. If a system is hardened with e.g. SUNWjass, and /etc/default/init has CMASK set to 027, Kiosk sessions fail. (Tested on recent Solaris / SRSS versions)

Haven't had the time to report this, but maybe you can do this :-)

Posted by Mika on April 16, 2008 at 10:10 AM PDT #

What about running xVM on the x86 Sun Ray server so that we can have the two builds of Nevada on x86 as well. This also brings xVM into the "real world" testing matrix. [ Might be better to use a newer x86 machine than the V40z though, particularly something with hardware assist for xVM ].

Posted by Darren Moffat on April 16, 2008 at 12:26 PM PDT #

We're running Nevada Build 73 here. Hopefully we'll have time and resources to upgrade again soon.

Posted by Joshua Clulow on April 17, 2008 at 12:27 AM PDT #

Post a Comment:

Name:
E-Mail:
URL:

Your Comment:

HTML Syntax: NOT allowed

Archives
Language
Links
Referrers