Tom: well a whole classroom full of people running JDS on the sunrays pretty much kills them
Kristin: oh bummer
Tom: ran the memory right out
Kristin: wow
Tom: the systems spend too much time paging
Tom: cde and they run fine
Kristin: hmm
Tom: it sucked
Tom: we had to get everyone in JDS to log out and log back in
Tom: I'm not a big fan of sunrays today
Kristin: what is the sunray server?
Tom: there are 2 v240's
Kristin: those are new arent they?
Tom: yes
Kristin: and how many sunrays in the lab?
Tom: 32
 
Top on one of the servers:
 

last pid:  8832;  load averages:  6.64,  7.17,  4.44             
     15:23:41
496 processes: 475 sleeping, 15 running, 3 zombie, 3 on cpu
CPU states: 11.8% idle, 66.9% user, 21.3% kernel,  0.0% iowait,  0.0% swap
Memory: 2048M real, 39M free, 3553M swap in use, 1973M swap free
Tom:    PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  8798 fffffff   15  47    0  128M   53M run      0:03  5.12% java
  8658 aaaa       8  52    0  113M   66M sleep    0:05  4.52% mozilla-bin
  5563 fffffff    1  21    0   80M   35M cpu/0    0:09  3.69% Xsun
  8828 fffffff   15   1    0  146M   44M run      0:01  3.67% java
  4024 aaaa       1  53    0   84M   30M sleep    0:13  3.15% Xsun
  7624 qqqqqqqq   8  59    0  110M   45M run      0:07  2.07% mozilla-bin
 26536 oooooooo   3  24    0  122M   63M run      0:44  2.03% mozilla-bin
 26362 mmmmmmmm   1  51    0   36M   28M sleep    0:05  1.86% Xsun
 25426 oooooooo   1  59    0   97M   39M sleep    0:36  1.85% Xsun
 24654 qqqqqqqq   1  30    0   41M   30M sleep    0:13  1.32% Xsun
  8225 fffffff   19  59    0  149M   41M sleep    0:04  1.22% java
 20619 cccccccc   1  43    0   76M   27M sleep    0:10  1.15% Xsun
  7329 fffffff    1  53    0   64M   32M cpu/0    0:01  0.91% metacity
  6838 ggggg     19  58    0  144M   36M sleep    0:05  0.87% java
  3824 sssss     19  56    0  149M   39M run      0:09  0.81% java
  5226 aaaa      19  47    0  149M   39M sleep    0:07  0.70% java
  2083 wwwwww    19  59    0  144M   39M run      0:09  0.69% java

 
vmstat output:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr m0 m1 m2 m1   in   sy   cs us sy id
 0 0 0 687760 977984  3  21  4  2  3  0 20  1  1  1  0  366  737  553  0  1 99
 13 0 1 3148808 60592 921 7577 2580 0 0 0 0 225 113 114 18 2850 22816
5966 70 30 0
 10 0 1 3254736 151744 1062 6150 4451 8 8 0 0 115 59 57 441 3456 19750
3917 67 33 0
 24 0 1 3256128 159080 760 5836 1204 0 0 0 0 107 54 54 17 1531 20498
3289 78 22 0
 7 0 1 3248296 147712 869 9398 982 0 0 0 0 95 49 49 19 1786 18958 3722 69 31 0

 
So, they are getting more RAM and hoping that will make things better. People were not happy to be told they have to run CDE until further notice. It is things like this that are not going to leave the students with a good impression of Solaris and Sun hardware.
 
I like the idea behind the Sunray. Tom tells me they are really easy to admin. I like the fact that I can stick my little card into one and get all my stuff just like I left it. Someday I want to do that on any computer, anywhere. But, if we're going to get to that point, then we, the developers, need to get out of the "it runs fine on my desktop" mindset.
 
I had never really considered the memory usage of JDS compared to CDE before. As soon as he told me about this, I had to go find out some more information. The first web page I came across was a fellow Sun blogger, John Rice. He had been following the initial tweaking of Gnome 2.0 and wanted to see how the memory usage was now. He determined that JDS was using around 35M of private and 45M of shared memory. Looking at the top output from the Sunray server, that seems reasonable. Each of those Xsun instances is using anywhere from 36MB to 97MB, with most in the 70-90MB range, with 30MB or so more reserved. John believes that all this memory usage in JDS is because its init functions are pulling in every library under the Sun.
 
I started peeking at other web pages and found another interesting discussion at osnews.com. It says:  

"We received reports that GNOME was orders of magnitude slower than CDE on Sun Rays. To verify and measure this, I designed and ran some performance tests in order to compare the time and bandwidth usage of GNOME (JDS) with that of CDE on Sun Rays. The tests measure the time it takes to display data using various desktop applications: Browser, StarOffice and Terminal."

 
This is another Sun person, Johan Steyn. He basically uses tcpdump to count bytes sent between the Sunray and the server. What I found as interesting were some of the comments such as "That's why you run CDE on your old SPARCstations, and Gnome/JDS on your dual-AMD64 boxen." and "Personally its very close to being a perfect environment for me. i would like better fast user switching. I don't think it is bloated. its rare that my system ever goes to the page file." It's rare that his system has to page? If a desktop system might be taxed enough by JDS to start paging, does that mean we expect Sunray server supporting 15 Sunrays to be at least, if not more, powerful than 15X a current desktop? I think expecting our customers to buy a couple of T2000's (at $16k-26k a piece) to support a lab of 32 Sunrays might be a bit unreasonable.
 
It is not just Gnome using up memory. Looking at the top output, java and mozilla are using up even more memory. I took a peek at my own system, running Solaris Express s10_52 (yea I know, I need to upgrade... in my copious spare time). From my system I see:
 

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  355 kristin    1  49    0   63M   58M sleep   8:17  0.59% Xsun
 1320 kristin    6  59    0   75M   63M sleep   2:22  0.51% mozilla-bin
  511 kristin    1  49    0   16M   10M sleep   0:14  0.09% gnome-terminal
  497 kristin    1  59    0   56M 8352K sleep   1:24  0.07% metacity
  501 kristin    1  59    0   62M   13M sleep   8:44  0.05% gnome-panel
  495 kristin    1  59    0 3720K 2016K sleep   0:26  0.01% gnome-smproxy
  503 kristin    4  59    0   71M   20M sleep   0:04  0.01% nautilus
  505 kristin    1  59    0   54M 5960K sleep   0:27  0.00% galf-server
  479 kristin    1  59    0   10M 7488K sleep   0:00  0.00% gconfd-2
  362 root       7  59    0 2640K 1448K sleep   1:22  0.00% mibiisa
  576 root       2  49    0 4456K 2480K sleep   0:39  0.00% automountd
  693 kristin   13  39   10   99M   67M sleep   0:24  0.00% java
  456 kristin    1  59    0 1880K  592K sleep   0:15  0.00% dsdm
   65 root       7  59    0 3464K  184K sleep   0:13  0.00% picld
  481 kristin    1  59    0 4960K 2848K sleep   0:03  0.00% xscreensaver

 
Xsun is using about the same but my mozilla, which has been running all day and is also running my email, is using almost half the memory as the mozillas on Tom's Sunrays. My java, which is 1.5, is using significantly less memory as well. Tom testing running mozilla again on the Sunray server for me and at startup it was using 98Mb, after loading 4 web pages it was at 104MB. Just adding up the memory (RES column) on my system by me (and ignoring numbers under 1MB), I get 231 MB. Imagine that multiplied by 32 users, and we have 7392 MB. Maybe only 1/3 of that is private, that is about what John Rice found, then we have 2464 MB just in private memory needed for the 32 users (I sure hope my math is just wrong). I can see why 4GB across his two servers might not be enough memory. Let's hope no one launches StarOffice.
 
All of this goes back to what I said at the beginning. I am sure the developers for each of these applications look at the memory usage (I sure hope they look!) and think, 100MB, that is not a big deal. Alone, it is not. Added with every other 100MB application people run just to have a minimally functioning desktop (web broswer, email, file browser) and then adding in common tools like a word processor or IM client and it starts to add up.
 
So, how many Sunrays should we expect a server to support? According to an article on unixville.com "The recommended server configuration for an average office with 50 active Sun Ray appliances is a Sun E250 with dual processors, 1 Gig of RAM, dual 100-Mbps Fast Ethernet controllers, and two disks to spread the swap space onto.". 50 users and 1 GB of RAM? Not if we want them to run JDS. Okay, the article is 1 1/2 years old, but has the memory usage really changed that much in 1 1/2 years? My build, s10_52 is from Feb 2004, before that article and an E250 with 1GB could not come close to supporting 50 Sunrays running Gnome + Mozilla + Java.
 
What is my point? There is a major disconnect between the folks considering the system requirements for applications such as Gnome and the Sunray technology, or really any thin client. I don't want to see Sunrays left behind with CDE. Can JDS be changed to use less memory? A lot of JDS fans like what the "bloat" provides them; anti-aliased fonts, pretty graphics, lots of functionality. JDS is certainly not the only GUI suffering from memory hog syndrome. OS X is a major memory hog, but it sure is pretty. What is the solution? Well, I guess step one is get more memory for those Sunray servers. I think the long term solution is for developers to stop using memory just because and start being smart about it. Yea, an individual machine may have 1 GB of memory to use, but we have to remember these applications are used other places besides our dual opteron desktop boxes. Customer feedback, its is where its at... you can't get enough.